From 0cd4d80e5757725192d1e0854b1489ee0198975d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 001/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_alpha_complex.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_geodesic_mesh.nxdl.xml # contributed_definitions/NXcg_grid.nxdl.xml # contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_marching_cubes.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_polyline_set.nxdl.xml # contributed_definitions/NXcg_roi_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml # contributed_definitions/NXcg_unit_normal_set.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- .../NXcg_primitive_set.nxdl.xml | 212 ++++++ .../NXcomponent_em.nxdl.xml | 69 ++ .../NXcoordinate_system.nxdl.xml | 143 ++++ .../NXcrystal_structure.nxdl.xml | 280 ++++++++ contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 ++ contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 ++ contributed_definitions/NXcs_gpu_obj.nxdl.xml | 39 ++ contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 ++ contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 ++ contributed_definitions/NXem_adf.nxdl.xml | 65 ++ contributed_definitions/NXem_base.nxdl.xml | 389 +++++++++++ .../NXem_conventions_ebsd.nxdl.xml | 230 +++++++ .../NXem_correlation.nxdl.xml | 245 +++++++ .../NXem_ebsd_conventions.nxdl.xml | 610 ------------------ contributed_definitions/NXem_eds.nxdl.xml | 144 +++++ contributed_definitions/NXem_eels.nxdl.xml | 79 +++ contributed_definitions/NXem_img.nxdl.xml | 63 ++ contributed_definitions/NXem_method.nxdl.xml | 47 ++ contributed_definitions/NXem_msr.nxdl.xml | 96 +++ contributed_definitions/NXem_sim.nxdl.xml | 60 ++ .../NXimage_c_set.nxdl.xml | 247 +++++++ .../NXimage_r_set.nxdl.xml | 100 +++ .../NXimage_r_set_diff.nxdl.xml | 179 +++++ .../NXinteraction_vol_em.nxdl.xml | 66 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 +++++++++++ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 + .../NXms_mtex_config.nxdl.xml | 310 +++++++++ contributed_definitions/NXms_odf.nxdl.xml | 171 +++++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 ++++ contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 +++++++++++++ contributed_definitions/NXroi.nxdl.xml | 34 + .../nyaml/NXcg_primitive_set.yaml | 136 ++++ .../nyaml/NXcomponent_em.yaml | 39 ++ .../nyaml/NXcoordinate_system.yaml | 86 +++ .../nyaml/NXcrystal_structure.yaml | 178 +++++ .../nyaml/NXcs_cpu_obj.yaml | 12 + .../nyaml/NXcs_cpu_sys.yaml | 21 + .../nyaml/NXcs_gpu_obj.yaml | 12 + .../nyaml/NXcs_gpu_sys.yaml | 20 + .../nyaml/NXcs_mm_obj.yaml | 21 + contributed_definitions/nyaml/NXem_adf.yaml | 28 + contributed_definitions/nyaml/NXem_base.yaml | 297 +++++++++ .../nyaml/NXem_conventions.yaml | 296 +++++++++ .../nyaml/NXem_conventions_ebsd.yaml | 125 ++++ .../nyaml/NXem_correlation.yaml | 191 ++++++ contributed_definitions/nyaml/NXem_eds.yaml | 80 +++ contributed_definitions/nyaml/NXem_eels.yaml | 39 ++ contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 ++ contributed_definitions/nyaml/NXem_sim.yaml | 34 + .../nyaml/NXimage_c_set.yaml | 140 ++++ .../nyaml/NXimage_r_set.yaml | 45 ++ .../nyaml/NXimage_r_set_diff.yaml | 123 ++++ contributed_definitions/nyaml/NXms_ipf.yaml | 299 +++++++++ .../nyaml/NXms_ipf_set.yaml | 9 + .../nyaml/NXms_mtex_config.yaml | 187 ++++++ contributed_definitions/nyaml/NXms_odf.yaml | 99 +++ .../nyaml/NXms_odf_set.yaml | 9 + contributed_definitions/nyaml/NXms_pf.yaml | 59 ++ .../nyaml/NXms_pf_set.yaml | 9 + contributed_definitions/nyaml/NXms_recon.yaml | 315 +++++++++ contributed_definitions/nyaml/NXroi.yaml | 9 + 65 files changed, 7504 insertions(+), 633 deletions(-) create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_obj.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml delete mode 100644 contributed_definitions/NXem_ebsd_conventions.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml create mode 100644 contributed_definitions/NXroi.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcomponent_em.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_mm_obj.yaml create mode 100644 contributed_definitions/nyaml/NXem_adf.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_conventions.yaml create mode 100644 contributed_definitions/nyaml/NXem_conventions_ebsd.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXimage_c_set.yaml create mode 100644 contributed_definitions/nyaml/NXimage_r_set.yaml create mode 100644 contributed_definitions/nyaml/NXimage_r_set_diff.yaml create mode 100644 contributed_definitions/nyaml/NXms_ipf.yaml create mode 100644 contributed_definitions/nyaml/NXms_ipf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_mtex_config.yaml create mode 100644 contributed_definitions/nyaml/NXms_odf.yaml create mode 100644 contributed_definitions/nyaml/NXms_odf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_pf.yaml create mode 100644 contributed_definitions/nyaml/NXms_pf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_recon.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml new file mode 100644 index 000000000..6ce5370a3 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a (central) processing unit (C)PU of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml new file mode 100644 index 000000000..3c5b6c26a --- /dev/null +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a graphic processing unit (GPU) of a computer. + + + + Given name of the GPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml new file mode 100644 index 000000000..e2b247079 --- /dev/null +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -0,0 +1,51 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a memory in a memory system. + + + + Qualifier for the type of random access memory. + + + + + + Total amount of data which the medium can hold. + + + + + + Given name to the I/O unit. + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml new file mode 100644 index 000000000..64534699c --- /dev/null +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -0,0 +1,65 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml deleted file mode 100644 index 7ef85f871..000000000 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ /dev/null @@ -1,610 +0,0 @@ - - - - - - - Conventions for rotations and coordinate systems to interpret EBSD data. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, e.g. rolling direction. - - - - - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Name or alias assigned to the y-axis base vector, e.g. transverse direction. - - - - - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Name or alias assigned to the z-axis base vector, e.g. normal direction. - - - - - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - - Details about the sample/specimen reference frame. - - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - - - - - - - - - - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - - Details about the detector reference frame. - - - - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml new file mode 100644 index 000000000..64c945c99 --- /dev/null +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml new file mode 100644 index 000000000..3ef371809 --- /dev/null +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of images in real space. + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml index a6beeb648..59c71c10e 100644 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -1,36 +1,56 @@ - + - + + - Base class for storing details about a modelled shape of interaction volume. + Base class for describing the interaction volume of particle-matter interaction. - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. + 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 are possible. - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy Further details on how the interaction volume can be quantified is available in the literature for example: - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml new file mode 100644 index 000000000..776eb0a6c --- /dev/null +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_ipf` instances. + + A collection of inverse pole figure approximations. + + + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml new file mode 100644 index 000000000..b77834bb6 --- /dev/null +++ b/contributed_definitions/NXroi.nxdl.xml @@ -0,0 +1,34 @@ + + + + + + Base class to describe a region-of-interest analyzed. + + + + Details about processing steps. + + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml new file mode 100644 index 000000000..78870cc26 --- /dev/null +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. +# `point Electronic GmbH `_ +type: group +NXcomponent_em(NXobject): + name(NX_CHAR): + doc: | + Given name to the component e.g stage, lens C1, etc. + description(NX_CHAR): # NXidentifier + doc: | + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + (NXfabrication): + (NXprogram): + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml new file mode 100644 index 000000000..73097d5ca --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + Computer science description of a (central) processing unit (C)PU of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_cpu_obj(NXobject): + name(NX_CHAR): + doc: | + Given name of the CPU. Users should be as specific as possible. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml new file mode 100644 index 000000000..5eaf8f0ea --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_cpu_sys(NXobject): + cpuID(NXcs_cpu_obj): + doc: | + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml new file mode 100644 index 000000000..04468b7b2 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + Computer science description of a graphic processing unit (GPU) of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_gpu_obj(NXobject): # NXcircuit_board ? + name(NX_CHAR): + doc: | + Given name of the GPU. Users should be as specific as possible. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml new file mode 100644 index 000000000..dee199330 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml @@ -0,0 +1,20 @@ +category: base +doc: | + Computer science description of a system of coprocessor or graphics processors. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_gpu_sys(NXobject): + gpuID(NXcs_gpu_obj): + doc: | + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_mm_obj.yaml b/contributed_definitions/nyaml/NXcs_mm_obj.yaml new file mode 100644 index 000000000..d1fead8c8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_mm_obj.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Computer science description of a memory in a memory system. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_mm_obj(NXobject): + technology(NX_CHAR): + doc: | + Qualifier for the type of random access memory. + # make an enumeration + max_physical_capacity(NX_NUMBER): + doc: | + Total amount of data which the medium can hold. + unit: NX_ANY + # NX_BIT + name(NX_CHAR): + doc: | + Given name to the I/O unit. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml new file mode 100644 index 000000000..b7011639e --- /dev/null +++ b/contributed_definitions/nyaml/NXem_adf.yaml @@ -0,0 +1,28 @@ +category: base +doc: | + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_adf(NXem_method): + IMAGE_R_SET(NXimage_r_set): + half_angle_interval(NX_NUMBER): + doc: | + Annulus inner (first value) and outer (second value) half angle. + unit: NX_ANGLE + dim: (2,) + # all information about annular dark field images is composed from + # the NXimage_r_set_em base class diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml new file mode 100644 index 000000000..7835d9a65 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_conventions.yaml @@ -0,0 +1,296 @@ +category: base +# symbols: +doc: | + Conventions for rotations and coordinate systems to interpret crystal orientation + and other data and results collected with electron microscopy research. + + Documenting explicitly all used conventions and coordinate systems is + the decisive context whereby many results from electron microscopy are + at all interpretable. + +# This base class provides several sets of such assumptions and conventions. +# Further base classes should be defined when specific techniques and methods +# demand further specifications or have specialized demands. NXem_conventions_ebsd +# is an example for such method-specific base class to summarize key conventions +# for Electron Backscatter Diffraction (EBSD). + +# What is could be a best practice for application definition developers +# who would like to describe an electron microscopy case where multiple +# methods and/or detectors are used. In this case one should define a +# method-specific base class like the template NXem_conventions_ebsd. +# Even though this may come at a cost of some duplicated information where +# the same physical detector is used in different ways, i.e. the signal collect +# from the detector is interpreted in a different way. +# As in most cases established types of signal and thus detectors are used +# (secondary electron, backscattered electron, etc.) one could equally use +# just one NXem_conventions base class instance in an application definition +# and use detector_reference_frame as a template. For each method and detector +# one then creates one NXprocess group named detector_reference_frame1, +# detector_reference_frame2, detector_reference_frame3, and so on and so forth +# and adds inside that NXprocess and use the depends_on field. + +# What is considered best practice in an application definition with multiple +# NXentry instances? In this case each NXentry instance should have an own +# NXspecimen instance and thus the NXem_conventions instance should be place +# inside that NXentry. This enables to group multiple experiments on multiple +# samples together without setting a constraint that in all these instances +# the conventions have to be the same. + +# However, best practice is the conventions should be expressed explicitly +# and they should whenever possible be as simple as possible and as few +# as possible to support users with understanding the content of the application +# definition. +type: group +NXem_conventions(NXobject): + # mandatory information about used or + # assumed reference frame and rotation conventions + rotation_conventions(NXobject): + doc: | + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + 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, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + enumeration: [undefined, zxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, p_plus_one, p_minus_one] + processing_reference_frame(NXcoordinate_system): + doc: | + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of coordinate system. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. rolling direction. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. transverse direction. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. normal direction. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + sample_reference_frame(NXcoordinate_system): + doc: | + Details about the sample/specimen reference frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. long edge. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. shortest edge. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + detector_reference_frameID(NXcoordinate_system): + doc: | + Details about the detector reference frame for a specific detector. + \@depends_on(NX_CHAR): + doc: | + Reference to the specifically named :ref:`NXdetector` instance + for which these conventions in this :ref:`NXprocess` group apply + (e.g. /entry1/instrument/detector1). + type(NX_CHAR): + doc: | + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge as some landmark on the detector. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. long edge as some landmark on the detector. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. short edge as some landmark on the detector. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + # conventions specific for EBSD + (NXem_conventions_ebsd): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml b/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml new file mode 100644 index 000000000..1ec180e23 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml @@ -0,0 +1,125 @@ +category: base +# symbols: +doc: | + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. +type: group +NXem_conventions_ebsd(NXem_conventions): + gnomonic_projection_reference_frame(NXcoordinate_system): + doc: | + Details about the gnomonic projection reference frame. + type(NX_CHAR): + doc: | + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of coordinate system. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, in_the_pattern_centre] + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + pattern_centre(NXprocess): + doc: | + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + 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? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + enumeration: [undefined, top, right, bottom, left] + x_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + enumeration: [undefined, north, east, south, west] + 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? + For further details inspect the help button of + xaxis_boundary_convention. + enumeration: [undefined, top, right, bottom, left] + y_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + enumeration: [undefined, north, east, south, west] + + # distance_convention: + # doc: | + # How is the third of the three pattern centre parameter values, + # the (distance) parameter DD, normalized. Which convention + # is followed. We are aware that specifying one of the options here + # also implicitly comes with conventions for some of the parameter + # requested in this ELN. For now we would rather like to ask + # the users though to be specific also to learn how such an ELN + # will be used in practice. + # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXimage_c_set.yaml b/contributed_definitions/nyaml/NXimage_c_set.yaml new file mode 100644 index 000000000..8dcd85706 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_c_set.yaml @@ -0,0 +1,140 @@ +category: base +doc: | + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `FFTW by M. Frigo and S. G. Johnson `_ + * `Intel MKL by the Intel Co. `_ + * `cuFFT by the NVidia Co. `_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. +symbols: + n_images: | + Number of images in the (hyper)stack. + n_k: | + Number of pixel per image in the slowest direction. + n_j: | + Number of pixel per image in the slow direction. + n_i: | + Number of pixel per image in the fast direction. +type: group +NXimage_c_set(NXimage_set): + # details about the FFT library used could for instance be stored in the + # NXprocess group which the NXimage_c_set base class can borrow from its + # NXimage_set parent base class + # process information are composable from the NXimage_set base class + stack(NXdata): + doc: | + Image stack. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + # axis_k(NX_NUMBER): + # doc: | + # Pixel coordinate center along k direction. + # unit: NX_ANY # NX_RECIPROCAL_LENGTH + # dim: (n_k,) + # \@long_name(NX_CHAR): + # doc: | + # Coordinate along j direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + hyperstack(NXdata): + doc: | + Image hyperstack. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_k(NX_NUMBER): + doc: | + Pixel coordinate center along k direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set.yaml b/contributed_definitions/nyaml/NXimage_r_set.yaml new file mode 100644 index 000000000..f0437e6e6 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_r_set.yaml @@ -0,0 +1,45 @@ +category: base +doc: | + Specialized base class container for reporting a set of images in real space. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXimage_r_set(NXimage_set): + # process information are composable from the NXimage_set base class + stack(NXdata): + doc: | + Image (stack). + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_images, n_y, n_x) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml new file mode 100644 index 000000000..79ca31b16 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml @@ -0,0 +1,123 @@ +category: base +doc: | + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. `_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. `_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. +symbols: + n_sc: | + Number of scanned points. Scan point may have none, one, or more pattern. + n_p: | + Number of diffraction pattern. + n_y: | + Number of pixel per pattern in the slow direction. + n_x: | + Number of pixel per pattern in the fast direction. +type: group +NXimage_r_set_diff(NXimage_r_set): + pattern_type(NX_CHAR): + doc: | + Category which type of diffraction pattern is reported. + enumeration: [kikuchi] + stack(NXdata): + doc: | + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + scan_point_identifier(NX_INT): + doc: | + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + unit: NX_UNITLESS + dim: (n_p,) + intensity(NX_NUMBER): + doc: | + Intensity of the diffraction pattern. + unit: NX_UNITLESS + dim: (n_p, n_y, n_x) + # n_p fast 2, n_y faster 1, n_x fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name(NX_CHAR): + doc: | + Pattern intensity + # \@signal: intensity + # \@axes: [pattern_identifier, ypos, xpos] + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@pattern_identifier_indices: 2 + pattern_identifier(NX_INT): + doc: | + Pattern are enumerated starting from 0 to n_p - 1. + unit: NX_UNITLESS + dim: (n_p,) + \@long_name(NX_CHAR): + doc: | + Pattern identifier + # the following fields are taken from the NXimage_r_set base class + # axis_y(R): + # axis_x(R): + +# If we envision a (knowledge) graph for EBSD it consists of individual sub-graphs +# which convey information about the specimen preparation, the measurement of +# the specimen in the electron microscope, the indexing of the collected +# Kikuchi pattern stack, eventual post-processing of the indexed orientation +# images via similarity grouping algorithms to yield (grains, texture). +# Conceptually, these post-processing steps are most frequently serving +# the idea how can one reconstruct so-called microstructural features +# (grains, phases, interfaces) to infer material properties. +# In practice this calls for workflows which quantify correlations between +# the spatial arrangement of the microstructural features, the individual +# (thermodynamic, chemo-mechanical) properties of the features with the +# properties of materials at a coarser scale. +# With NXem and related NXms base classes we propose a covering +# and general solution how to handle such (meta)data with NeXus. diff --git a/contributed_definitions/nyaml/NXms_ipf.yaml b/contributed_definitions/nyaml/NXms_ipf.yaml new file mode 100644 index 000000000..11bfc5983 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_ipf.yaml @@ -0,0 +1,299 @@ +category: base +doc: | + Base class to store an inverse pole figure (IPF) mapping (IPF map). +symbols: + # how to make this optional + n_z: | + Number of pixel along the z slowest direction. + n_y: | + Number of pixel along the y slow direction. + n_x: | + Number of pixel along the x fast direction. + n_rgb: | + Number of RGB values along the fastest direction, always three. + d: | + Dimensionality of the mapping (either 2 or 3). +type: group +NXms_ipf(NXprocess): + \@depends_on(NX_CHAR): + doc: | + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + projection_direction(NX_NUMBER): + doc: | + The direction along which orientations are projected. + unit: NX_UNITLESS + dim: (3,) + input_grid(NXcg_grid): + doc: | + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when exported from the tech partner's file format representation. + output_grid(NXcg_grid): + doc: | + 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + interpolation(NX_CHAR): + doc: | + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + enumeration: [nearest_neighbour] + map(NXdata): + doc: | + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + # \@signal: data + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + data(NX_NUMBER): + # assume a mapping with step size 0.5 micron + # we need to distinguish + # pixel position, i.e. 0, 1, 2, 3, unit px + # answers in which pixel on the map but map is disconnected from sample surface context + # calibrated pixel position 0., 0.5, 1.0, 1.5, unit micron + # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context + # calibrated pixel position including the offset of the original coordinate system + # 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 + doc: | + Inverse pole figure color code for each map coordinate. + unit: NX_UNITLESS + dim: (n_y, n_x, 3) # | (n_z, n_y, n_x, 3) + axis_z(NX_NUMBER): + doc: | + Pixel center coordinate calibrated for step size along the z axis of the map. + unit: NX_LENGTH + dim: (n_z,) + # \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center coordinate calibrated for step size along the y axis of the map. + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center coordinate calibrated for step size along the x axis of the map. + dim: (n_x,) + # \@long_name(NX_CHAR): + # title: + legend(NXdata): + doc: | + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the matrix + of a rasterized image which is rendered by the backend tool gets + copied into an RGB matrix to offer a default plot. + # \@signal: data + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + data(NX_NUMBER): + # hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! + doc: | + Inverse pole figure color code for each map coordinate. + unit: NX_UNITLESS + dim: (n_y, n_x, 3) + axis_y(NX_NUMBER): + doc: | + Pixel along the y-axis. + unit: NX_UNITLESS + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + doc: | + Pixel along the x-axis. + unit: NX_UNITLESS + dim: (n_x,) + # \@long_name(NX_CHAR): + # title: + +# keep this for now for FAIRmat internal documentation +# It is important to mention that we cannot assume, at least for now, +# that the parser which writes to an NXem_ebsd-compliant file is also +# responsible or capable at all of computing the inverse pole figure +# color keys and maps itself. This cannot be assumed working because +# this mapping of orientation data uses involved mathematical algorithms +# and functions which not every tools used in the EBSD community is capable +# of using or is for sure not using in exactly the same way. +# +# Currently, we assume it is the responsibilty of the tool used which +# generated the data under on_the_fly_indexing to compute these +# plots and deliver these to the parser. +# +# Specific case studies have been explored by the experiment team of +# Area B of the FAIRmat project to realize and implement such mapping. +# +# The first case study uses the H5OINA format and the pyxem/orix library. +# As orix is a Python library, the coloring is performed by the em_om parser. +# +# The second case study uses MTex and its EBSD color coding model. +# As MTex is a Matlab tool, an intermediate format is written from MTex +# first which stores these pieces of information. The parser then pulls +# these data from the intermediate Matlab-agnostic representation and +# supplements the file with missing pieces of information as it is +# required by NXem_ebsd. +# +# The third case study shows how a generic set of Kikuchi pattern +# can be loaded with the em_om parser. The pattern are loaded directly +# from a ZIP file and mapped to an simulation image section for now. +# +# The fourth case study uses the DREAM.3D package which provides an own +# set of EBSD data post-processing procedures. DREAM.3D documents the +# processing steps with a pipeline file which is stored inside DREAM.3D +# output files. In this case study, the parser reads the DREAM.3D file +# and maps data relevant from the perspective of NXem_ebsd plus adds +# relevant IPF color maps as they were computed by DREAM.3D. +# Given that in this case the origin of the data is the DREAM.3D file +# again provenance is kept and more details can be followed upon when +# resolving origin. +# +# These examples offer a first set of suggestions on how to make EBSD +# data injectable into research data management system using schemes +# which themselves are agnostic to the specific RDMS and interoperable. +# Steps of collecting the raw data and post-processing these with custom +# scripts like MTex or commercial tools so far are mainly undocumented. +# The limitation is that a program which consumes results or dump files +# from these tools may not have necessarily all the sufficient information +# available to check if the injected orientation data and color models +# are matching the conventions which a user or automated system has +# injected into an electronic lab notebook from which currently the em_om +# parser collects the conventions and stores them into this NXem_ebsd instance. +# The immediate benefit of the here presented NXem_ebsd concept though +# is that the conventions and reference frame definitions are expected +# in an ELN-agnostic representation to make NXem_ebsd a generally useful +# data scheme for EBSD. +# +# Ideally, the em_om parser would load convention-compliant EBSD data +# and use subsequently a community library to transcode/convert orientation +# conventions and parameterized orientation values. Thereafter, convention- +# compliant default plot(s) could be created that would be truely interoperable. +# +# However, given the variety of post-processing tools available surplus +# the fact that these are not usually executed along standardized +# post-processing workflows which perform exactly the same algorithmic steps, +# this is currently not a practically implementable option. Indeed, first +# developers who wish to implement this would first have to create a library +# for performing such tasks, mapping generally between conventions, +# i.e. map and rotate coordinate systems at the parser level. +# +# The unfortunate situation in EBSD is that due to historical reasons +# and competitive strategies, different players in the field have +# implemented (slightly) different approaches each of which misses +# some part of a complete workflow description which is behind EBSD analyses: +# Sample preparation, measurement, indexing, post-processing, paper... +# +# The here exemplified default plot do not so far apply relevant rotations +# but takes the orientation values as they come from the origin and using +# coloring them as they come. It is thus the scientists responsibility to +# enter and check if the respective dataset is rotation-conventions-wise +# consistent and fit for a particular task. +# +# Ideally, with all conventions defined it can be possible to develop +# a converter which rotates the input data. This application definition +# does not assume this and users should be aware of this limitation. +# +# The key point is that the conventions however are captured and this is +# the most important step to the development of such a generic transcoder +# for creating interoperable EBSD datasets. +# +# Currently the conventions remain in the mind or manual lab book of the +# respective scientists or technicians instead of getting stored and +# communicated with research papers that are written based on +# specific dataset, i.e. database entries. +# +# The default gridded representation of the data should not be +# misinterpreted as the only possible way how EBSD data and OIM +# maps can be created! +# +# Indeed, the most general case is that patterns are collected for +# scan points. The scan generator of an electron microscope is instructed +# to steer the beam in such a way across the specimen surface that the +# beam illuminates certain positions for a certain amount time (usually +# equally-spaced and spending about the same amount of time at each +# position). +# +# Therefore, scan positions can be due to such regular flight plans and +# represent sampling on lines, line stacks, rectangular regions-of- +# interests, but also could instruct spiral, random, or adaptive scans +# instead of tessellations with square or hexagonal pixels. +# +# The majority of EBSD maps is though is reporting results for a regular +# grid (square, hexagon). What matters though in terms of damage induced +# by the electron beam and signal quality is the real electron dose +# history, i.e. for how long the beam exposed which location of the +# specimen. Especially when electron charging occurs (i.e. an excess +# amount of charge accumulates due to e.g. poor conducting away of this +# charge or an improper mounting, too high dose, etc. such details are +# relevant. +# +# Specifically, the default visualization is an inverse pole-figure (IPF) +# map with the usual RGB color coding. Different strategies and +# normalization schemes are in use to define such color coding. +# +# Finally, we should mention that each ipf_map represents data for +# scan points indexed as one phase. The alias/name of this phase should +# be stored in phase_name, the phase_identifier give an ID which must +# not be zero as this value is reserved for non-indexed / null model scan +# points. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXms_ipf_set.yaml b/contributed_definitions/nyaml/NXms_ipf_set.yaml new file mode 100644 index 000000000..a783655a2 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_ipf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_ipf` instances. + + A collection of inverse pole figure approximations. +# symbols: +type: group +NXms_ipf_set(NXprocess): + (NXms_ipf): diff --git a/contributed_definitions/nyaml/NXms_mtex_config.yaml b/contributed_definitions/nyaml/NXms_mtex_config.yaml new file mode 100644 index 000000000..b8fee982d --- /dev/null +++ b/contributed_definitions/nyaml/NXms_mtex_config.yaml @@ -0,0 +1,187 @@ +category: base +doc: | + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. `_ and + the `MTex source code `_ for details. +type: group +NXms_mtex_config(NXobject): + conventions(NXcollection): + doc: | + Reference frame and orientation conventions. + Consult the `MTex docs `_ for details. + x_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + # check against v5.12 + z_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + a_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + b_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + euler_angle(NX_CHAR): + doc: | + TODO with MTex developers + enumeration: [unknown, undefined, bunge] + plotting(NXcollection): + doc: | + Settings relevant for generating plots. + font_size(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + inner_plot_spacing(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + outer_plot_spacing(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + marker_size(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + figure_size(NX_NUMBER): + doc: | + TODO with MTex developers + show_micron_bar(NX_BOOLEAN): + doc: | + True if MTex renders a scale bar with figures. + show_coordinates(NX_BOOLEAN): + doc: | + True if MTex renders a grid with figures. + pf_anno_fun_hdl: + doc: | + Code for the function handle used for annotating pole figure plots. + color_map(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_UNITLESS + dim: (i, 3) + default_color_map(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_UNITLESS + dim: (i, 3) + # phase_color_order: + # doc: | + # TODO with MTex developers + # unit: NX_UNITLESS + # dim: (i,) + color_palette(NX_CHAR): + degree_char(NX_CHAR): + doc: | + TODO with MTex developers + arrow_char(NX_CHAR): + doc: | + TODO with MTex developers + marker(NX_CHAR): + doc: | + TODO with MTex developers + marker_edge_color(NX_CHAR): + doc: | + TODO with MTex developers + marker_face_color(NX_CHAR): + doc: | + TODO with MTex developers + hit_test(NX_BOOLEAN): + doc: | + TODO with MTex developers + miscellaneous(NXcollection): + doc: | + Miscellaneous other settings of MTex. + mosek(NX_BOOLEAN): + doc: | + TODO with MTex developers + generating_help_mode(NX_BOOLEAN): + doc: | + TODO with MTex developers + methods_advise(NX_BOOLEAN): + doc: | + TODO with MTex developers + stop_on_symmetry_mismatch(NX_BOOLEAN): + doc: | + TODO with MTex developers + inside_poly(NX_BOOLEAN): + doc: | + TODO with MTex developers + text_interpreter: + numerics(NXcollection): + doc: | + Miscellaneous settings relevant for numerics. + eps(NX_NUMBER): + doc: | + Return value of the Matlab eps command. + unit: NX_UNITLESS + fft_accuracy(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # NX_LENGTH or NX_RECIPROCAL_LENGTH? + max_stwo_bandwidth(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # radiant? + max_sothree_bandwidth(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # radiant? + system(NXcollection): + doc: | + Miscellaneous settings relevant of the system where MTex runs. + memory(NX_NUMBER): + doc: | + TODO with MTex developers + open_gl_bug(NX_BOOLEAN): + doc: | + TODO with MTex developers + save_to_file(NX_BOOLEAN): + doc: | + TODO with MTex developers + path(NXcollection): + doc: | + Collection of paths from where MTex reads information and code. + mtex(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + data(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + cif(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + ebsd(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + pf(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + odf(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + tensor(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + example(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + import_wizard(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + pf_extensions(NX_CHAR): + doc: | + List of file type suffixes for which MTex assumes + texture/pole figure information. + ebsd_extensions(NX_CHAR): + doc: | + List of file type suffixes for which MTex assumes EBSD content. + # version as an instance of (NXprogram) one for MTex one for Matlab diff --git a/contributed_definitions/nyaml/NXms_odf.yaml b/contributed_definitions/nyaml/NXms_odf.yaml new file mode 100644 index 000000000..92ad96589 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_odf.yaml @@ -0,0 +1,99 @@ +category: base +doc: | + Base class to store an orientation distribution function (ODF) computation. +symbols: + n_varphi_one: | + Number of pixel per varphi section plot along the varphi_one fastest direction. + n_capital_phi: | + Number of pixel per varphi section plot along the capital_phi slow direction. + n_varphi_two: | + Number of pixel per varphi section plot along the varphi_two slowest direction. + k: | + Number of local maxima evaluated in the component analysis. +type: group +NXms_odf(NXprocess): + configuration(NXobject): + doc: | + Details about the algorithm used for computing the ODF. + crystal_symmetry_point_group(NX_CHAR): + doc: | + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + specimen_symmetry_point_group(NX_CHAR): + doc: | + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + kernel_halfwidth(NX_NUMBER): + doc: | + Halfwidth of the kernel. + unit: NX_ANGLE + kernel_name(NX_CHAR): + doc: | + Name of the kernel. + resolution(NX_NUMBER): + doc: | + Resolution of the kernel. + unit: NX_ANGLE + kth_extrema(NXobject): + kth(NX_UINT): + doc: | + Number of local maxima evaluated for the ODF. + unit: NX_UNITLESS + # value of kth should be k + location(NX_NUMBER): + doc: | + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + unit: NX_ANGLE + dim: (k, 3) + theta(NX_NUMBER): + doc: | + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + unit: NX_ANGLE + volume_fraction(NX_NUMBER): + doc: | + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + unit: NX_ANY + dim: (k,) + phi_two_plot(NXdata): + doc: | + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + # \@signal: intensity + # \@axes: [varphi_two, capital_phi, varphi_one] + # \@varphi_one_indices: 0 + # \@capital_phi: 1 + # \@varphi_two_indices: 2 + intensity(NX_NUMBER): + doc: | + ODF intensity at probed locations relative to + null model of a completely random texture. + unit: NX_DIMENSIONLESS + dim: (n_varphi_two, n_capital_phi, n_varphi_one) + varphi_one(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\varphi_1` direction. + unit: NX_ANGLE + dim: (n_varphi_one,) + # \@long_name(NX_CHAR): + varphi_two(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\varphi_2` direction. + unit: NX_ANGLE + dim: (n_varphi_two,) + # \@long_name(NX_CHAR): + capital_phi(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\Phi` direction. + unit: NX_ANGLE + dim: (n_capital_phi,) + # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_odf_set.yaml b/contributed_definitions/nyaml/NXms_odf_set.yaml new file mode 100644 index 000000000..5ea1c4d6c --- /dev/null +++ b/contributed_definitions/nyaml/NXms_odf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. +# symbols: +type: group +NXms_odf_set(NXprocess): + (NXms_odf): diff --git a/contributed_definitions/nyaml/NXms_pf.yaml b/contributed_definitions/nyaml/NXms_pf.yaml new file mode 100644 index 000000000..09ab12f78 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_pf.yaml @@ -0,0 +1,59 @@ +category: base +doc: | + Base class to store a pole figure (PF) computation. +symbols: + n_y: | + Number of pixel per pole figure in the slow direction. + n_x: | + Number of pixel per pole figure in the fast direction. +type: group +NXms_pf(NXprocess): + configuration(NXobject): + doc: | + 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 + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + specimen_symmetry_point_group(NX_CHAR): + doc: | + Point group assumed for processing induced *sample symmetries* + (according to International Table of Crystallography). + halfwidth(NX_NUMBER): + doc: | + Halfwidth of the kernel. + unit: NX_ANGLE + miller_indices(NX_CHAR): + doc: | + Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + resolution(NX_NUMBER): + doc: | + Resolution of the kernel. + unit: NX_ANGLE + pf(NXdata): + doc: | + Pole figure. + # \@signal: intensity + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + intensity(NX_NUMBER): + doc: | + Pole figure intensity. + unit: NX_UNITLESS + dim: (n_y, n_x) + axis_y(NX_NUMBER): + doc: | + Pixel center along y direction in the equatorial plane of + a stereographic projection of the unit sphere. + unit: NX_ANY + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + doc: | + Pixel center along x direction in the equatorial plane of + a stereographic projection of the unit sphere. + unit: NX_ANY + dim: (n_x,) + # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_pf_set.yaml b/contributed_definitions/nyaml/NXms_pf_set.yaml new file mode 100644 index 000000000..afd785f15 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_pf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. +# symbols: +type: group +NXms_pf_set(NXprocess): + (NXms_pf): diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml new file mode 100644 index 000000000..bd6825bac --- /dev/null +++ b/contributed_definitions/nyaml/NXms_recon.yaml @@ -0,0 +1,315 @@ +# position would need another depends_on the specific coordinate system used, currently we assume McStas +# roi1/ebsd/microstructure1 +category: base +doc: | + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + # in so-called linear intercept analysis we observe + # one-dimensional sections of either projections (see below) + # or true one-dimensional cuts across a volume of material + # n_icept: | + # The number of linear intercepts defined. + # n_c_one: | + # The number of crystal projections segmented by crossing (projected or real) interfaces + # n_i_one: | + # The number of crossings + # two-dimensional projections of characterized in reality three-dimensional objects + # using E. E. Underwood notation + # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" + n_c_two: | + The number of crystal projections. + n_i_two: | + The number of interface projections. + n_t_two: | + The number of assumed triple junction projections aka triple points. + # three-dimensional real objects, volumetrically characterized + # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions + n_c: | + The number of crystals. + n_i: | + The number of interfaces + n_t: | + The number of triple lines + n_q: | + The number of quadruple junctions. +type: group +NXms_recon(NXobject): + # as e.g. a result of one grain reconstruction with MTex or othe + # grain reconstruction software in commercial tools + # the idea is we may wish to run as many grain reconstructions as we want... + # add details about the processing + configuration(NXprocess): + doc: | + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + # maybe a depends_on what was the input however if the group is injected + # in an roi1/ebsd instance isnt this information implicit? + dimensionality(NX_POSINT): + doc: | + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + algorithm(NX_CHAR): + doc: | + Which algorithm is used to reconstruct the features. + enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] + disorientation_threshold(NX_NUMBER): + doc: | + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + unit: NX_ANGLE + # the result of running one grain reconstruction + # ms_feature_set1 + # we could also enumerate instances ms_feature_setID here because configuration + # may specify a range of different parameter resulting in multiple ms_feature_sets + # dimensionality(N) composed from NXms_feature_set base: + # controlled vocabulary of base class instances to be used to inform about the + # discretization of these features instances to discretize the features + # wherever possible the computational geometry specific instances whose + # purpose is only to support/represent the discretization of the features should + # be separated out from the materials engineering interpretation of what these + # features are, i.e. a grain that is measured with a 2d section ends up + # modelled as an projection of that real 3d grain object + # the model is discretized usign a polyline which models the location of the + # interface at the required here coarse-grained continuum picture + points(NXcg_point_set): + lines(NXcg_polyline_set): + surfaces(NXcg_triangle_set): + volumes(NXcg_polyhedron_set): + + # domain-specific, i.e. microstructural features + # ONE DIMENSIONAL FEATURES + + # TWO DIMENSIONAL FEATURES + crystal_projections(NXms_feature_set): + doc: | + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + number_of_crystals(NX_UINT): + doc: | + Number of crystals. + unit: NX_UNITLESS + crystal_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + crystal_identifier(NX_INT): + doc: | + Identifier used for crystals for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + number_of_phases(NX_UINT): + doc: | + How many phases are distinguished + unit: NX_UNITLESS + phase_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + unit: NX_UNITLESS + phase_identifier(NX_INT): + # \@depends_on(NX_CHAR): + doc: | + Identifier used for phase for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + # properties of crystal_projections aka grain properties + boundary_contact(NX_BOOLEAN): + doc: | + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + dim: (n_c_two,) + orientation_spread(NX_NUMBER): + doc: | + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + unit: NX_ANGLE + dim: (n_c_two,) + (NXrotation_set): + area(NX_NUMBER): + doc: | + Calibrated area of surrounded by the polyline about each crystal. + unit: NX_AREA + dim: (n_c_two,) + interface_projections(NXms_feature_set): + # grain boundaries have a network of line-like defects, its explicit description + # often generates unnecessary information duplication and cluttering, + # therefore here a compact and suggestion how to store such data + doc: | + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + # topology + # i) Set of pair of crystals sharing an interface + crystals(NX_INT): + doc: | + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + # ii) Set of pair of topologically connected triple points + triple_points(NX_INT): + doc: | + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + # alternatively which polyline of adjoining interfaces + # properties, descriptors + length(NX_NUMBER): + doc: | + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + unit: NX_LENGTH + dim: (n_i_two,) + interface_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + interface_identifier(NX_INT): + doc: | + Identifier for each interface using explicit indexing. + unit: NX_UNITLESS + dim: (n_i_two,) + triple_line_projections(NXms_feature_set): + # only for 2D, quad junction is the equivalent for 3D is not a triple_line + # four alternative descriptors with different strength to specify spatial + # or logical information about the triple junction feature set. + # the explicit description often generating unnecessary information duplication + doc: | + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + \@discretization(NX_CHAR): + doc: | + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + # another view to describe a triple junction is via its topology/connection expressed either via + # i) triplet of interface identifier + number_of_triple_points(NX_UINT): + doc: | + Number of triple points. + unit: NX_UNITLESS + triple_point_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + triple_point_identifier(NX_INT): + doc: | + Identifier for each triple point using explicit indexing. + unit: NX_UNITLESS + dim: (n_t_two,) + location(NX_INT): + doc: | + Set of triple point identifiers. + unit: NX_UNITLESS + dim: (n_t_two,) + \@depends_on(NX_CHAR): + doc: | + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + interfaces(NX_INT): # aka topology or interfaces + doc: | + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + # ii) a triplet of line segment identifier whereby the point-like features + # is assumed discretized via three polylines representing interfaces + polylines(NX_INT): + doc: | + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + # the difference in the interpretation of interfaces and polylines + # is that the interface resolves interface (e.g. phase boundary names) + # while polylines resolves segments within the set of named geometric primitive + # instances! + # add all sort of other qualitative or quantitive descriptors (triple junction + # energy, volume etc), i.e properties of that triple point diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From b693886cae6f3a27e8488d8319bf07a446e834a5 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 002/198] Make nxdl # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- contributed_definitions/NXcg_primitive_set.nxdl.xml | 2 +- contributed_definitions/NXcomponent_em.nxdl.xml | 2 +- contributed_definitions/NXcoordinate_system.nxdl.xml | 2 +- contributed_definitions/NXcrystal_structure.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- contributed_definitions/NXem_conventions_ebsd.nxdl.xml | 2 +- contributed_definitions/NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- contributed_definitions/NXimage_c_set.nxdl.xml | 2 +- contributed_definitions/NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXinteraction_vol_em.nxdl.xml | 2 +- contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- contributed_definitions/NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- contributed_definitions/NXroi.nxdl.xml | 2 +- 32 files changed, 32 insertions(+), 32 deletions(-) diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index ff211fce0..ccb0cef29 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -76,7 +76,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -123,7 +123,7 @@ they share the same position in space but have different identifiers.--> mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - + @@ -156,7 +156,7 @@ they share the same position in space but have different identifiers.--> array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 435597722..f639e3b3f 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -49,7 +49,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - + @@ -63,7 +63,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer * 2 - inner - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index ccb0cef29..b64c3467d 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -2,9 +2,9 @@ mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - + @@ -156,7 +156,7 @@ they share the same position in space but have different identifiers.--> array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index f639e3b3f..435597722 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -49,7 +49,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - + @@ -63,7 +63,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer * 2 - inner - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 95f0e8c41..a39efa0eb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -63,7 +63,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -72,7 +72,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 950437b7471ebdc540e37db42feb0452a3a0d78f Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 008/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_alpha_complex.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_grid.nxdl.xml # contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyline_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- requirements.txt | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 0b34306826eddc8a0e4a32b81b230bf0c44cc35f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 010/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_ellipsoid_set.nxdl.xml # base_classes/NXcg_face_list_data_structure.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_hexahedron_set.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_parallelogram_set.nxdl.xml # base_classes/NXcg_point_set.nxdl.xml # base_classes/NXcg_polygon_set.nxdl.xml # base_classes/NXcg_polyhedron_set.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXcg_tetrahedron_set.nxdl.xml # base_classes/NXcg_triangle_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 111 +- base_classes/NXcg_cylinder_set.nxdl.xml | 128 +- base_classes/NXcg_ellipsoid_set.nxdl.xml | 94 +- .../NXcg_face_list_data_structure.nxdl.xml | 146 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 44 +- base_classes/NXcg_grid.nxdl.xml | 90 +- .../NXcg_half_edge_data_structure.nxdl.xml | 105 +- base_classes/NXcg_hexahedron_set.nxdl.xml | 152 +- base_classes/NXcg_marching_cubes.nxdl.xml | 35 +- base_classes/NXcg_parallelogram_set.nxdl.xml | 159 +- base_classes/NXcg_point_set.nxdl.xml | 71 +- base_classes/NXcg_polygon_set.nxdl.xml | 156 +- base_classes/NXcg_polyhedron_set.nxdl.xml | 126 +- base_classes/NXcg_polyline_set.nxdl.xml | 124 +- base_classes/NXcg_roi_set.nxdl.xml | 43 +- base_classes/NXcg_sphere_set.nxdl.xml | 74 +- base_classes/NXcg_tetrahedron_set.nxdl.xml | 129 +- base_classes/NXcg_triangle_set.nxdl.xml | 95 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 26 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 33 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXevent_data_em_set.nxdl.xml | 32 - base_classes/NXfabrication.nxdl.xml | 51 - base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 33 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 94 files changed, 3901 insertions(+), 11247 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXevent_data_em_set.nxdl.xml delete mode 100644 base_classes/NXfabrication.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 1b3e3446e..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the alpha shape, for now 2 or 3. - - - - - - The number of edges. - - - - - The number of faces. - - - - - The number of cells. - - - + + - Computational geometry description of alpha shapes or wrappings to primitives. + Computational geometry of alpha shapes or alpha wrappings about primitives. For details see: @@ -60,22 +33,17 @@ convex hull of a point set.--> * https://dx.doi.org/10.1145/174462.156635 for 3D, * https://dl.acm.org/doi/10.5555/871114 for weighted, and * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings in CGAL, the Computational Geometry Algorithms Library. As a starting point, we follow the conventions of the CGAL library. - - - - - - - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. + Type of alpha complex following the terminology used by CGAL for now. + + Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes + created using the alpha_wrapping algorithm. @@ -83,69 +51,72 @@ convex hull of a point set.--> - + - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. + Are singular faces removed, i.e. has the alpha complex + been regularized or not. - - - - - + - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. + The alpha parameter, i.e. the radius of the alpha-sphere that + is used when computing the alpha complex. + - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. + The offset distance parameter used when computing alpha_wrappings. - + + - Point cloud for which the alpha shape or wrapping should be computed. + Point cloud for which the alpha shape or wrapping has been computed. - + - Triangle soup for which the alpha wrapping should be computed. + Triangle soup for which the alpha wrapping has been computed. - + - A meshed representation of the resulting shape. + Triangle mesh representing the alpha complex. - - + + + Set of tetrahedra representing the volume inside the alpha complex. + + diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5e5e8860..acf97b44e 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + 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 cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius 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 lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index 38a448a0e..32d2c636b 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 2. + The dimensionality of the space in which the members are assumed embedded. - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. + Computational geometry description of a set of ellipsoids. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - If all ellipsoids in the set have the same half-axes. + Radius of the half axes. + + Use if all ellipsoids in the set have the same half-axes. @@ -89,47 +54,12 @@ - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. + Half-axes radii of each ellipsoid. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index ea8faee3e..54cce1279 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,96 +60,90 @@ - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their 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). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + - Dimensionality. + Dimensionality of the primitives described. - + - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. + Number of 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. + 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. + Number of faces of the primitives. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer used to distinguish vertices explicitly. + Integer identifier to distinguish all vertices explicitly. @@ -156,7 +151,7 @@ - Integer used to distinguish edges explicitly. + Integer used to distinguish all edges explicitly. @@ -164,23 +159,21 @@ - Integer used to distinguish faces explicitly. + Integer used to distinguish all faces explicitly. - + Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + 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 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. + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -189,7 +182,7 @@ - The edges are stored as a pairs of vertex identifier values. + The edges are stored as pairs of vertex identifier. @@ -198,7 +191,7 @@ - Array of identifiers from vertices which describe each face. + 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 @@ -207,7 +200,7 @@ Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -216,18 +209,23 @@ - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that 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 twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + 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: diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 59fb6e4d6..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,28 +30,26 @@ Computational geometry description of a geodesic mesh. - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. + 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. - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: + 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>`_ - * `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. - Here, especially the section on subdivision schemes is relevant. + 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. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index f3cbc2853..b827fe1e9 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,36 +33,35 @@ - The cardinality or total number of cells/grid points. + The cardinality or total number of cells aka grid points. - Number of boundaries of the bounding box or primitive to the grid. + Number of boundaries of the bounding box or primitive housing the grid. - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Examples of numerical methods where grids are used + are spectral-solver based crystal plasticity or other stencil methods like + phase-field or cellular automata. - - - - - - - - - + + + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` + 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. @@ -78,49 +77,23 @@ - + Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. + + 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. + not be used. Instead, use the coordinate field. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cells. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish cells for explicit indexing. - - - - - - + Position of each cell in Euclidean space. @@ -141,24 +114,25 @@ should constraints on the grid be place here or not--> - A tight bounding box or sphere or bounding primitive about the grid. + A tight bounding box about the grid. - - + - How many distinct boundaries are distinguished? + 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. + Name of domain boundaries of the simulation box/ROI + e.g. left, right, front, back, bottom, top. - diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 81c66fb2b..260f16e1b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -54,41 +54,74 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - - + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + 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. + + + + + + + + Number of faces of the primitives. + + - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. + 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_set` for further details. - + - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The face identifier zero is reserved for the NULL face ! + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. - + - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. + 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_set` for further details. - + The position of the vertices. @@ -97,7 +130,7 @@ - + Identifier of the incident half-edge. @@ -105,7 +138,7 @@ - + Identifier of the (starting)/associated half-edge of the face. @@ -113,7 +146,7 @@ - + The identifier of the vertex from which this half-edge is outwards pointing. @@ -121,7 +154,7 @@ - + Identifier of the associated oppositely pointing half-edge. @@ -129,7 +162,7 @@ - + If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. @@ -138,7 +171,7 @@ - + Identifier of the next half-edge. @@ -146,7 +179,7 @@ - + Identifier of the previous half-edge. @@ -159,9 +192,9 @@ 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>`_ + * `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_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml index 96c2d7123..57ec8a8e0 100644 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ b/base_classes/NXcg_hexahedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,63 +41,53 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Computational geometry description of a set of hexahedra in Euclidean space. - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. This class can also be used to describe cuboids or cubes, axis-aligned or not. The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + applied scientists and computational geometry experts an approach whereby + different specific views can be implemented using the same base class: - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. + * 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 the hexahedra is offered which serve different computational + 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. - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. + As a specialization of the :ref:`NXcg_primitive_set` 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 especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). + 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 codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries + 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 - tight fitting box about an arbitrary object. In general such boxes are + tightly fitting box about an arbitrary object. In general, such boxes are rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. + exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. + Qualifier for the shape of each hexahedron. @@ -105,9 +96,9 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. + Qualifier 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. @@ -115,8 +106,11 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific 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. @@ -124,31 +118,24 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific coordinate system. + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. - + - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + Volume of each hexahedron. - - - - - - - + - Total area (of all six faces) of each hexahedron. + Total (surface) area (of all six faces) of each hexahedron. @@ -176,64 +163,31 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Only to be used if is_box is present. In this case, this field describes whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. + axes of the coordinate system. - - + - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. + Combined storage of all primitives of all hexahedra. - - + - Disentangled representations of the mesh of specific hexahedra. + Individual storage of each hexahedron. - - + - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each hexahedron as a graph. diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 5699cfb14..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,8 +30,8 @@ Computational geometry description of the marching cubes algorithm. - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. @@ -39,35 +39,22 @@ marching cubes algorithm implementation is operating. - + Reference to the specific implementation of marching cubes used. See for example the following papers for details about how to identify a DOI which specifies the implementation used: - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ The value placed here should be a DOI. If there are no specific DOI or details write not_further_specified, or give at least a free-text description. - - - Commercial or otherwise given name to the program which was used. - - - - Program version plus build number, commit hash, or description of - an ever persistent resource where the source code of the program - and build instructions can be found so that the program can be - configured in such a manner that the result file is ideally - recreatable yielding the same results. - - - + diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml index ca4a56984..f20cc4777 100644 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ b/base_classes/NXcg_parallelogram_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,151 +33,74 @@ - Computational geometry description of a set of parallelograms in Euclidean space. + Computational geometry description of a set of parallelograms. - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + 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: - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. + * 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 we would like to specify the polygon - which is parallelogram represents. + * 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. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. + Parallelograms 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. - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. + 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_set` for the generalization in 3D. An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries + 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 - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. + 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. - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - + - Qualifier often used to describe the length of an edge within - a specific coordinate system. + To specify which parallelogram is a rectangle. - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. + 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. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - + - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. + Combined storage of all primitives of all parallelograms. - - + - Disentangled representations of the mesh of specific parallelograms. + Individual storage of each parallelogram. - + diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index e5c351839..bea36a1a9 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 1. + The dimensionality. @@ -38,61 +38,50 @@ - Computational geometry description of a set of points in Euclidean space. + Computational geometry description of a set of points. - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. + 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_set` instance which specifies the + points' locations. + + This is a frequent situation in experiments and computer simulations, where + positions of points are taken at the same point in time (real time or + simulated physical time). Thereby, the storage of redundant time stamp + information per point is considered as obsolete. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - + - Integer used to distinguish points for explicit indexing. + Coordinates of the points. - + + - + - The array of point coordinates. + (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. - + - - + - The optional array of time for each vertex. + ISO8601 with local time zone offset for each point. - + - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. + ISO8601 with local time zone offset that serves as the reference + for values in the field time. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index 4969f2e83..6f6cf68e6 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -52,7 +52,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Computational geometry description of a set of polygons in Euclidean space. - Polygons are related are specialized polylines: + 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. @@ -65,63 +65,40 @@ somewhat redundant as there is NXoff_geometry but easier to understand As three-dimensional objects, a set of polygons can be used to define the hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own + the specific :ref:`NXcg_polyhedron_set` 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_set to describe such even more - complex primitives. + complex primitives instead of abusing this base class for such purposes. - - - - - - - - - + - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + The total number of vertices in the set. - + + - Integer used to distinguish polygons for explicit indexing. + Combined storage of all primitives of all polygons. - - - - - - + + - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. + Individual storage of the mesh of each polygon. - - - - - - - - - - + + + Individual storage of each polygon as a graph. + + + - The accumulated length of the polygon edge. + For each polygon its accumulated length along its edges. @@ -129,7 +106,8 @@ properties of the polygon primitives--> - Array of interior angles. There are many values per polygon as number_of_vertices. + 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. @@ -150,78 +128,4 @@ properties of the polygon primitives--> - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index e3a6e99fe..af373d821 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -52,56 +53,21 @@ for clean graph-based descriptions of polyhedra.--> - Computational geometry description of a polyhedra in Euclidean space. + Computational geometry description of a set of polyhedra in Euclidean space. - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. + 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 more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. + 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_set`. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - + The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. + are counted for each polyhedron. @@ -109,86 +75,40 @@ for clean graph-based descriptions of polyhedra.--> - Area of each of the four triangular faces of each tetrahedron. + Area of each of faces. - + The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. + are counterd for each polyhedron. - Length of each edge of each tetrahedron. + Length of each edge. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. + Combined storage of all primitives of all polyhedra. - - + - Disentangled representations of the mesh of specific polyhedron. + Individual storage of each polyhedron. - - + - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each polygon as a graph. - diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index b64c3467d..898a56acd 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -50,58 +50,36 @@ multiple vertices possible with the same point coordinates but different names.- - Computational geometry description of a set of polylines in Euclidean space. + 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 positive traversal along the polyline when walking - from the start vertex to the end/last vertex. + The sequence describes the positive traversal along the polyline when + walking from the first to the last vertex. - - - - + - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. + Reference to an instance of :ref:`NXcg_point_set` which defines + the location of the vertices that are referred to in the + NXcg_polyline_set instance. - - + + - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. + The total number of vertices that have different positions. - - - - + - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - polylines. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + The total number of vertices, irrespective of their eventual uniqueness. - + - Integer used to distinguish polylines for explicit indexing. + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. @@ -111,73 +89,57 @@ multiple vertices possible with the same point coordinates but different names.- 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.--> - + Positions of the vertices which support the members of the polyline set. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + Users are encouraged to reduce the 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 twice. + or are counted several times. - Sequence of vertex identifiers which describe each polyline. + 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 in a junction, say the second vertex is shared and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. + there are only five unique positions. This suggests to store five + unique vertices. - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: + 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 start vertex of the first polyline, + 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 polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: + 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, the vertices of the + n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - - - - The length of each polyline. - - - - - - - - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - - - - - - - diff --git a/base_classes/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi_set.nxdl.xml index 0b14fa5b4..edbd5b2a5 100644 --- a/base_classes/NXcg_roi_set.nxdl.xml +++ b/base_classes/NXcg_roi_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + 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_set` 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 + disencouraged, 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 to hold geometric primitives. + 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_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index e50192cf8..b676aedf9 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..bc8b3e301 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,57 +33,13 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Computational geometry description of a set of tetrahedra in Euclidean space. + Computational geometry description of a set of tetrahedra. - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most + Among hexahedral elements, tetrahedral elements are one of the most frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. + objects in continuum-field simulations. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - Area of each of the four triangular faces of each tetrahedron. @@ -107,69 +58,29 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - + Interior angle values for each tetrahedron. + The quadruplet of angles is a sequence following the order of the vertices. + The angle is the angle at the specific vertex. + + The sequence of the vertices follows their definition in tetrahedra. +detailed mesh-based representation--> - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe + Combined storage of all primitives of all tetrahedra. - - + - Disentangled representations of the mesh of specific tetrahedra. + Individual storage of each tetrahedron. - - + - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each tetrahedron as a graph. diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..092b43c08 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,61 +43,39 @@ - Computational geometry description of a set of triangles in Euclidean space. + Computational geometry description of a set of triangles. - - - - + - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Number of unique vertices in the triangle set. - + - Integer used to distinguish triangles for explicit indexing. + 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. - - - - - - + + - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. + 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. - - - - - - - - - - - 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. + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. @@ -106,27 +84,14 @@ properties of 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. + 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. - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index dd1d4d2ef..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -31,22 +31,8 @@ Computational geometry description of a mesh of triangles. The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. + triangles used must not be degenerated. - - A graph-based approach to describe the mesh when it is also desired diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 435597722..0f7df7c87 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -42,12 +44,14 @@ rather make this a set of vectors, irrespective whether these are unit or not--> 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_set` + so that this instance acts as the parent to define a context. - - - + - Direction of each normal + Direction of each normal - a unit normal. @@ -56,12 +60,13 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - Qualifier how which specifically oriented normal to its primitive each - normal represents. + Qualifier 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 - * 2 - inner + * 1 - outer unit normal vector + * 2 - inner unit normal vector diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index e5f40c95a..000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. - - - diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml deleted file mode 100644 index 5ec33932b..000000000 --- a/base_classes/NXfabrication.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Component of an instrument to store or place objects and specimens. + Computer science description of a memory in a memory system. - + + + Qualifier for the type of random access memory. + + + + - Given name/alias. + Total amount of data which the medium can hold. - + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From b16ee17001b3b3b394c46ee560d6744ebebddbb3 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 011/198] Make nxdl # Conflicts: # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_ellipsoid_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_hexahedron_set.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_parallelogram_set.nxdl.xml | 2 +- base_classes/NXcg_point_set.nxdl.xml | 2 +- base_classes/NXcg_polygon_set.nxdl.xml | 2 +- base_classes/NXcg_polyhedron_set.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 2 +- base_classes/NXcg_sphere_set.nxdl.xml | 2 +- base_classes/NXcg_tetrahedron_set.nxdl.xml | 2 +- base_classes/NXcg_triangle_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXcollectioncolumn.nxdl.xml | 104 - base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXpump.nxdl.xml | 43 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 68 files changed, 8639 insertions(+), 238 deletions(-) delete mode 100644 base_classes/NXcollectioncolumn.nxdl.xml delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. - - - - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. - - - - - Voltage applied to the extractor lens - - - - - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. - - - - - Distance between sample and detector entrance - - - - - Labelling of the lens setting in use. - - - - - The space projected in the angularly dispersive directions, real or reciprocal - - - - - - - - - The magnification of the electron lens assembly. - - - - - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - - diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml deleted file mode 100644 index 79574ecaa..000000000 --- a/base_classes/NXem_img.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml index e2b247079..76322751e 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 000000000..9f38b2d7b --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 14f3b8979ff73755df3fc5184760f0b521e7c671 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 012/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 ++-- base_classes/NXcg_cylinder_set.nxdl.xml | 4 ++-- base_classes/NXcg_ellipsoid_set.nxdl.xml | 4 ++-- base_classes/NXcg_face_list_data_structure.nxdl.xml | 4 ++-- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 ++-- base_classes/NXcg_grid.nxdl.xml | 4 ++-- base_classes/NXcg_half_edge_data_structure.nxdl.xml | 4 ++-- base_classes/NXcg_hexahedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_marching_cubes.nxdl.xml | 4 ++-- base_classes/NXcg_parallelogram_set.nxdl.xml | 4 ++-- base_classes/NXcg_point_set.nxdl.xml | 4 ++-- base_classes/NXcg_polygon_set.nxdl.xml | 4 ++-- base_classes/NXcg_polyhedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_polyline_set.nxdl.xml | 4 ++-- base_classes/NXcg_roi_set.nxdl.xml | 4 ++-- base_classes/NXcg_sphere_set.nxdl.xml | 4 ++-- base_classes/NXcg_tetrahedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_triangle_set.nxdl.xml | 4 ++-- base_classes/NXcg_triangulated_surface_mesh.nxdl.xml | 4 ++-- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 ++-- base_classes/NXprogram.nxdl.xml | 4 ++-- base_classes/NXregistration.nxdl.xml | 4 ++-- base_classes/NXspindispersion.nxdl.xml | 4 ++-- contributed_definitions/NXaberration.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model_ceos.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model_nion.nxdl.xml | 4 ++-- contributed_definitions/NXaperture_em.nxdl.xml | 4 ++-- contributed_definitions/NXapm.nxdl.xml | 4 ++-- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 ++-- contributed_definitions/NXcalibration.nxdl.xml | 4 ++-- contributed_definitions/NXcg_primitive_set.nxdl.xml | 4 ++-- contributed_definitions/NXchamber.nxdl.xml | 4 ++-- contributed_definitions/NXcoordinate_system.nxdl.xml | 4 ++-- contributed_definitions/NXcoordinate_system_set.nxdl.xml | 4 ++-- contributed_definitions/NXcorrector_cs.nxdl.xml | 4 ++-- contributed_definitions/NXcrystal_structure.nxdl.xml | 4 ++-- contributed_definitions/NXcs_computer.nxdl.xml | 4 ++-- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml | 4 ++-- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_prng.nxdl.xml | 4 ++-- contributed_definitions/NXcs_profiling.nxdl.xml | 4 ++-- contributed_definitions/NXcs_profiling_event.nxdl.xml | 4 ++-- contributed_definitions/NXebeam_column.nxdl.xml | 4 ++-- contributed_definitions/NXelectronanalyser.nxdl.xml | 4 ++-- contributed_definitions/NXem.nxdl.xml | 4 ++-- contributed_definitions/NXem_base.nxdl.xml | 4 ++-- contributed_definitions/NXem_correlation.nxdl.xml | 4 ++-- contributed_definitions/NXem_ebsd.nxdl.xml | 4 ++-- contributed_definitions/NXem_eds.nxdl.xml | 4 ++-- contributed_definitions/NXem_eels.nxdl.xml | 4 ++-- contributed_definitions/NXem_img.nxdl.xml | 4 ++-- contributed_definitions/NXem_method.nxdl.xml | 4 ++-- contributed_definitions/NXem_msr.nxdl.xml | 4 ++-- contributed_definitions/NXem_sim.nxdl.xml | 4 ++-- contributed_definitions/NXenergydispersion.nxdl.xml | 4 ++-- contributed_definitions/NXevent_data_em.nxdl.xml | 4 ++-- contributed_definitions/NXevent_data_em_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_edge_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_node_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_root.nxdl.xml | 4 ++-- contributed_definitions/NXibeam_column.nxdl.xml | 4 ++-- contributed_definitions/NXimage_c_set.nxdl.xml | 4 ++-- contributed_definitions/NXimage_r_set.nxdl.xml | 4 ++-- contributed_definitions/NXimage_set.nxdl.xml | 4 ++-- contributed_definitions/NXion.nxdl.xml | 4 ++-- contributed_definitions/NXisocontour.nxdl.xml | 4 ++-- contributed_definitions/NXlens_em.nxdl.xml | 4 ++-- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- contributed_definitions/NXms.nxdl.xml | 4 ++-- contributed_definitions/NXms_feature_set.nxdl.xml | 4 ++-- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 ++-- contributed_definitions/NXms_score_results.nxdl.xml | 4 ++-- contributed_definitions/NXoptical_system_em.nxdl.xml | 4 ++-- contributed_definitions/NXpump.nxdl.xml | 4 ++-- contributed_definitions/NXroi.nxdl.xml | 4 ++-- contributed_definitions/NXscanbox_em.nxdl.xml | 4 ++-- contributed_definitions/NXspectrum_set.nxdl.xml | 4 ++-- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 84 files changed, 168 insertions(+), 168 deletions(-) diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index e22a677c1..f613be7ec 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 48610a31d..a452dc99f 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml index 8ea85fb98..e7569c628 100644 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ b/base_classes/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> 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. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml index bfb868c47..3709be64d 100644 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ b/base_classes/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,15 +83,13 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index c2190590d..5d8a15310 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index 95c157ce1..c70810832 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -46,9 +46,7 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -100,7 +98,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand For each polygon its accumulated length along its edges. - + @@ -112,7 +110,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -124,7 +122,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand * 1 - convex, * 2 - concave - + diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index b087b0c79..00eaec95a 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 8b1283474..58d4d5796 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index 509347c51..34c5d8ca7 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index 7d994eb3e..fe215dd3e 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> 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_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml index aff5c9b71..7e9d834b8 100644 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -70,6 +70,7 @@ + Description of the type of the detector. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - - - - - Number of time points measured, the length of NXsample/time_points - - - - - Ellipsometry, complex systems, up to variable angle spectroscopy. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - - - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - - - An application definition for ellipsometry. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - An optional free-text description of the experiment. - - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - - - - - Specify the type of ellipsometry. - - - - - - - - - - - - - - Properties of the ellipsometry equipment. - - - - Name of the company which build the instrument. - - - - - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. - - - - - - What type of ellipsometry was used? See Fujiwara Table 4.2. - - - - - - - - - - - - - - - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - - Specify the used light source. Multiple selection possible. - - - - - - - - - - - - - If focussing 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 - focussing probes (lenses)? - - - - - Specify the angular spread caused by the focussing probes. - - - - - - Properties of the detector used. Integration time is the count time - field, or the real time field. See their definition. - - - - - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - - - - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - - - - - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - - - - - Specify the maximum value of revolutions of the rotating element - for each measurement. - - - - - - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range can - be stored in grating_dispersion. - - - - - - - - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - - - - - - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_observables) are - stored in the data array. - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/base_classes/NXcg_primitive_set.nxdl.xml +++ b/base_classes/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/base_classes/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/base_classes/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml deleted file mode 100644 index c67d8c8eb..000000000 --- a/base_classes/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 93b35cfef..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 97f1ebd1a..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 972ed6080..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/base_classes/NXmanipulator.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 51% rename from base_classes/NXmanipulator.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index dff2584fc..abdea5bbb 100644 --- a/base_classes/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,75 +21,67 @@ # # For further information, see http://www.nexusformat.org --> - + - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. + Deflectors as they are used e.g. in an electron analyser. - + - Name of the manipulator. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - A description of the manipulator. + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Type of manipulator, Hexapod, Rod, etc. + Name of the manufacturer who built/constructed the deflector. - + - Is cryocoolant flowing through the manipulator? + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Temperature of the cryostat (coldest point) + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - Power in the heater for temperature control. + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + - Temperature at the closest point to the sample. This field may also be found in - NXsample if present. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - Current to neutralize the photoemission current. This field may also be found in - NXsample if present. - - - - - Possible bias of the sample with trespect to analyser ground. This field may - also be found in NXsample if present. - - - - - Class to describe the motors that are used in the manipulator - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. Collection of axis-based translations and rotations to describe the location and - geometry of the manipulator as a component in the instrument. Conventions from - the NXtransformations base class are used. In principle, the McStas coordinate + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate system is used. The first transformation has to point either to another component of the system or . (for pointing to the reference frame) to relate it relative to the experimental setup. Typically, the components of a system should diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index e9bd12b89..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index d42af5a47..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 7881ae180f23da97f696891305d4ce08d70589d5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 016/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2034 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 12 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 20 +- .../NXcg_half_edge_data_structure.nxdl.xml | 26 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 12 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 10 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 165 ++ .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 32 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + .../NXcs_gpu_obj.nxdl.xml | 27 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 44 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 10 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 4 +- .../NXroi.nxdl.xml | 6 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 94 files changed, 7393 insertions(+), 7860 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (67%) create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXregistration.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (54%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename {base_classes => contributed_definitions}/NXroi.nxdl.xml (95%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index ad33f94aa..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2034 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..260f16e1b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -2,9 +2,9 @@ even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 4ffc77ba8..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 9d674f6b2..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index e3c52b3ef..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 000000000..38a448a0e --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 57% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 98e6e02b2..6ce5370a3 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a (central) processing unit (C)PU of a computer. - - + - Principle type of the pump. + Given name of the CPU. Users should be as specific as possible. - - - - - - - + diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 67% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index bc6d4c291..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Describes image registration procedures. - - + + - Has the registration been applied? + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Indicates the name of the last operation applied in the NXprocess sequence. + Qualifier for the type of random access memory. - + + - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. + Total amount of data which the medium can hold. - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - + + - Description of the procedures employed. + Given name to the I/O unit. + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXspindispersion.nxdl.xml b/base_classes/NXspindispersion.nxdl.xml deleted file mode 100644 index 28e16a8c8..000000000 --- a/base_classes/NXspindispersion.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments. - - - - Type of spin detector, VLEED, SPLEED, Mott, etc. - - - - - Figure of merit of the spin detector - - - - - Effective Shermann function, calibrated spin selectivity factor - - - - - Energy of the spin-selective scattering - - - - - Angle of the spin-selective scattering - - - - - Name of the target - - - - - Preparation procedure of the spin target - - - - - Date of last preparation of the spin target - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - Deflectors in the spin dispersive section - - - - - Individual lenses in the spin dispersive section - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 50% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 0034919dd..7ec26670c 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. + Container to hold NXevent_data_em instances of an electron microscope session. - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - - - - + diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 54% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index aaad75e98..1f940f079 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - 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/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 1eb89befb06320710f99a9cb409bf9e28b2d54f6 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 018/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 ++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 357 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + From 6fa9f40706c59e671882585371b1f15beb4d6d68 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jan 2024 21:52:39 +0100 Subject: [PATCH 020/198] Added changes relevant to use the refactored NXapm parser of pynxtools 0572bfa9df6f513325024185ed1f1c1901d0758c # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_msr.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXevent_data_apm_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXpeak.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXreflectron.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml # contributed_definitions/nyaml/NXapm_hit_finding.yaml # contributed_definitions/nyaml/NXapm_ranging.yaml # contributed_definitions/nyaml/NXapm_reconstruction.yaml # contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml # contributed_definitions/nyaml/NXevent_data_apm.yaml # contributed_definitions/nyaml/NXpeak.yaml --- contributed_definitions/NXapm.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 87 +++++++++ contributed_definitions/NXpulser_apm.nxdl.xml | 166 ++++++++++++++++++ contributed_definitions/NXreflectron.nxdl.xml | 56 ++++++ 4 files changed, 311 insertions(+), 2 deletions(-) create mode 100644 contributed_definitions/NXpeak.nxdl.xml create mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml create mode 100644 contributed_definitions/NXreflectron.nxdl.xml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml new file mode 100644 index 000000000..a57b1af0d --- /dev/null +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -0,0 +1,166 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + From 96c426743696af725bcc5dba3bba294d6474c7a2 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:27:41 +0100 Subject: [PATCH 021/198] Recompiled NXDLs from YAML using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 6 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 389 ------------------ .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 144 ------- contributed_definitions/NXem_eels.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 247 ----------- .../NXimage_r_set.nxdl.xml | 100 ----- .../NXimage_r_set_diff.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 4 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 26 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 12 +- contributed_definitions/NXms_pf.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 42 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 8 +- .../NXsimilarity_grouping.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 49 files changed, 152 insertions(+), 1046 deletions(-) delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_eds.nxdl.xml delete mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index c00dfc240..e5e5e8860 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 95f0e8c41..a39efa0eb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -63,7 +63,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -72,7 +72,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 59cee3ee9ba3924601c78a18d390b2b31bc766f4 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 024/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - + 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. + The cardinality of the set, i.e. the number of cylinders or cones. - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders in Euclidean space. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. - + + + + + + + - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - + + + + Integer used to distinguish members for explicit indexing. + + - - - + - Radius of the cylinder if all have the same radius. + The geometric center of each member. + + + + - + - Radii of the cylinder. + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. - + + + + + + + + - + - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + - + - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + - Lateral surface area + Interior volume of each cylinder - + - + - Area of the upper cap of each cylinder. + Lateral surface area - + - + - Area of the lower cap of each cylinder. + Area of the upper and the lower cap of each cylinder respectively. - + + - + - Sum of upper and lower cap areas and lateral surface area - of each cylinder. + Cap and lateral surface area for each cylinder. - + diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index f613be7ec..38a448a0e 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + 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 dimensionality, which has to be at least 2. - The cardinality of the set, i.e. the number of members. + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - Computational geometry description of a set of ellipsoids. + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. - + + + - Radius of the half axes. + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Use if all ellipsoids in the set have the same half-axes. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. - + - Half-axes radii of each ellipsoid. + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. - + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index a452dc99f..ea8faee3e 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -60,138 +59,146 @@ duplicate of an NXoff_geometry ?--> - Computational geometry of primitives via a face-and-edge-list data structure. + Computational geometry description of geometric primitives via a face and edge list. - Primitives must neither be degenerated nor self-intersect but can differ in - their 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). + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. - Although this description is storage efficient it is not well suited for - topological analyses though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or very detailed specification demands. + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - Dimensionality of the primitives described. + Dimensionality. - + - 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. + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. - + - + - Number of edges 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 edges. - - - - + - Number of faces of the primitives. + Number of faces. - Integer offset whereby the identifier of the first member - of the vertices differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the edges differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the faces differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer identifier to distinguish all vertices explicitly. + Integer used to distinguish vertices explicitly. - + - Integer used to distinguish all edges explicitly. + Integer used to distinguish edges explicitly. - + - Integer used to distinguish all faces explicitly. + Integer used to distinguish faces explicitly. - + - + 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. + 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 each - vertex is stored even though many share the same positions. + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. - + - The edges are stored as pairs of vertex identifier. + The edges are stored as a pairs of vertex identifier values. - + - The faces are stored as a concatenated array of vertex identifier tuples. + 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 @@ -200,32 +207,27 @@ duplicate of an NXoff_geometry ?--> 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}]`. + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - + - If true, indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted more - than once. + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. - If true, indicates that no edge is stored 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. + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + Specifies for each face which winding order was used if any: @@ -234,7 +236,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml index e7569c628..96c2d7123 100644 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ b/base_classes/NXcg_hexahedron_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,103 +40,117 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Computational geometry description of a set of hexahedra in Euclidean space. + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. This class can also be used to describe cuboids or cubes, axis-aligned or not. The class represents different access and description levels to offer both - applied scientists and computational geometry experts an approach whereby - different specific views can be implemented using the same base class: + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: - * 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. + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional computational + based view of the hexahedra is offered which serve different computational tasks: storage-oriented simple views or detailed topological/graph-based descriptions. Hexahedra are important geometrical primitives, which are among the most frequently used elements in finite element meshing/modeling. - As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). - An axis-aligned bounding box is a common data object in computational science - and 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 + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries of geometric primitives in techniques like kd-trees. An optimal bounding box is a common data object which provides the best - tightly fitting box about an arbitrary object. In general, such boxes are + tight 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. + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + - Qualifier for the shape of each hexahedron. + A qualitative description of each hexahedron/cuboid/cube/box. - + - 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 how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. - + - Qualifier often used to describe the 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 length of an edge within + a specific coordinate system. - + - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. + Qualifier often used to describe the length of an edge within + a specific coordinate system. - + - + - Volume of each hexahedron. + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - + + + + + + + - + - Total (surface) area (of all six faces) of each hexahedron. + Total area (of all six faces) of each hexahedron. - + @@ -145,7 +158,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +168,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -163,31 +176,64 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> 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. + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. - + - + + + - Combined storage of all primitives of all hexahedra. + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. - + + - Individual storage of each hexahedron. + Disentangled representations of the mesh of specific hexahedra. - + + - Individual storage of each hexahedron as a graph. + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml index 3709be64d..ca4a56984 100644 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ b/base_classes/NXcg_parallelogram_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,72 +33,151 @@ - Computational geometry description of a set of parallelograms. + Computational geometry description of a set of parallelograms in Euclidean space. - 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 parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: - * 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. + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. - Parallelograms 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. + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. - The term parallelogram will be used throughout this base class 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_set` for the generalization in 3D. + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. An axis-aligned bounding box is a common data object in computational science - and 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 + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries of geometric primitives in techniques like kd-trees. - An optimal bounding box is a common data object which provides the best, 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. + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + - + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + - To specify which parallelogram is a rectangle. + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. - + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + - Only to be used if is_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_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. - + + + + + + - Combined storage of all primitives of all parallelograms. + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. - + + - Individual storage of each parallelogram. + Disentangled representations of the mesh of specific parallelograms. - + diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index 5d8a15310..e5c351839 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality. + The dimensionality, which has to be at least 1. @@ -38,50 +38,61 @@ - Computational geometry description of a set of points. + Computational geometry description of a set of points in Euclidean space. - 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_set` instance which specifies the - points' locations. - - This is a frequent situation in experiments and computer simulations, where - positions of points are taken at the same point in time (real time or - simulated physical time). Thereby, the storage of redundant time stamp - information per point is considered as obsolete. + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. - + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + - Coordinates of the points. + Integer used to distinguish points for explicit indexing. - + - - + - (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. + The array of point coordinates. - + + - + - ISO8601 with local time zone offset for each point. + The optional array of time for each vertex. - + - + - ISO8601 with local time zone offset that serves as the reference - for values in the field time. + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index c70810832..4969f2e83 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + @@ -46,11 +46,13 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. - Polygons are specialized polylines: + Polygons are related are specialized polylines: * A polygon is a geometric primitive that is bounded by a closed polyline * All vertices of this polyline lay in the d-1 dimensional plane. @@ -63,54 +65,76 @@ descriptors.--> 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_set` 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 + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own base class e.g. NXcg_polytope_set to describe such even more - complex primitives instead of abusing this base class for such purposes. + complex primitives. - - - The total number of vertices in the set. - + + + + + - - + + + - Combined storage of all primitives of all polygons. + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - - + + - Individual storage of the mesh of each polygon. + Integer used to distinguish polygons for explicit indexing. - - + + + + + + - Individual storage of each polygon as a graph. + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. - + + + + + + + + + + - For each polygon its accumulated length along its edges. + The accumulated length of the polygon edge. - + - Interior angles for each polygon. There are as many values per polygon - as the are number_of_vertices. + Array of interior angles. There are many values per polygon as number_of_vertices. The angle is the angle at the specific vertex, i.e. between the adjoining edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -122,8 +146,82 @@ descriptors.--> * 1 - convex, * 2 - concave - + + + + + + + The center of mass of each polygon. + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index 00eaec95a..e3a6e99fe 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,62 +52,143 @@ for clean graph-based descriptions of polyhedra.--> - Computational geometry description of a set of polyhedra in Euclidean space. + Computational geometry description of a 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. + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. - For 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_set`. + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + - + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. - + - Area of each of faces. + Area of each of the four triangular faces of each tetrahedron. - + - + The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. - Length of each edge. + Length of each edge of each tetrahedron. - + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + - Combined storage of all primitives of all polyhedra. + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. - + + - Individual storage of each polyhedron. + Disentangled representations of the mesh of specific polyhedron. - + + - Individual storage of each polygon as a graph. + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/base_classes/NXcg_primitive_set.nxdl.xml +++ b/base_classes/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 58d4d5796..e50192cf8 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,10 +39,46 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> - Computational geometry description of a set of spheres. + Computational geometry description of a set of spheres in Euclidean space. - Each sphere can have a different radius but all need to have finite volume. + Each sphere can have a different radius. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + In the case that all spheres have the same radius. @@ -54,7 +89,32 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index 34c5d8ca7..a00b1464b 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,18 +38,62 @@ - Computational geometry description of a set of tetrahedra. + Computational geometry description of a set of tetrahedra in Euclidean space. - Among hexahedral elements, tetrahedral elements are one of the most + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + Area of each of the four triangular faces of each tetrahedron. - + @@ -53,34 +102,74 @@ Length of each edge of each tetrahedron. - + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + Array of interior angle values. For each tetrahedron the quadruplet of + angles is a sequence following the order of the vertices. The angle + is the angle at the specific vertex. TODO lexiographical order. + Winding order has to be interpreted to resolve the individual angles + between edges of adjoining face triangles meeting at each corner/vertex. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, c], [2, 12]]--> + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + - Combined storage of all primitives of all tetrahedra. + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe - + + - Individual storage of each tetrahedron. + Disentangled representations of the mesh of specific tetrahedra. - + + - Individual storage of each tetrahedron as a graph. + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index fe215dd3e..6e5ad2fc7 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,55 +43,90 @@ - Computational geometry description of a set of triangles. + Computational geometry description of a set of triangles in Euclidean space. - + + + + - Number of unique vertices in the triangle set. + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. - - + + - Combined storage of all primitives of all triangles. + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - - + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + - 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. + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. - + + + + + + + + + - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. + 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. - + - 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. + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. - + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system.nxdl.xml rename to base_classes/NXcoordinate_system.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcrystal_structure.nxdl.xml rename to base_classes/NXcrystal_structure.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_correlation.nxdl.xml rename to base_classes/NXem_correlation.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eels.nxdl.xml rename to base_classes/NXem_eels.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml similarity index 100% rename from contributed_definitions/NXreflectron.nxdl.xml rename to base_classes/NXreflectron.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index e5e5e8860..000000000 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 31e012644a6838b7232fb08372f9e2ea64b1adfb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 026/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_ellipsoid_set.nxdl.xml # base_classes/NXcg_face_list_data_structure.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_hexahedron_set.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_parallelogram_set.nxdl.xml # base_classes/NXcg_point_set.nxdl.xml # base_classes/NXcg_polygon_set.nxdl.xml # base_classes/NXcg_polyhedron_set.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXcg_tetrahedron_set.nxdl.xml # base_classes/NXcg_triangle_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 128 +- base_classes/NXcg_ellipsoid_set.nxdl.xml | 94 +- .../NXcg_face_list_data_structure.nxdl.xml | 146 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_hexahedron_set.nxdl.xml | 152 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_parallelogram_set.nxdl.xml | 159 +- base_classes/NXcg_point_set.nxdl.xml | 71 +- base_classes/NXcg_polygon_set.nxdl.xml | 156 +- base_classes/NXcg_polyhedron_set.nxdl.xml | 126 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_sphere_set.nxdl.xml | 74 +- base_classes/NXcg_tetrahedron_set.nxdl.xml | 129 +- base_classes/NXcg_triangle_set.nxdl.xml | 95 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXevent_data_em_set.nxdl.xml | 32 - base_classes/NXfabrication.nxdl.xml | 51 - base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 29 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 94 files changed, 3651 insertions(+), 10930 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXevent_data_em_set.nxdl.xml delete mode 100644 base_classes/NXfabrication.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (58%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + 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 cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius 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 lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index 38a448a0e..32d2c636b 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 2. + The dimensionality of the space in which the members are assumed embedded. - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. + Computational geometry description of a set of ellipsoids. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - If all ellipsoids in the set have the same half-axes. + Radius of the half axes. + + Use if all ellipsoids in the set have the same half-axes. @@ -89,47 +54,12 @@ - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. + Half-axes radii of each ellipsoid. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index ea8faee3e..54cce1279 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,96 +60,90 @@ - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their 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). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + - Dimensionality. + Dimensionality of the primitives described. - + - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. + Number of 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. + 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. + Number of faces of the primitives. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer used to distinguish vertices explicitly. + Integer identifier to distinguish all vertices explicitly. @@ -156,7 +151,7 @@ - Integer used to distinguish edges explicitly. + Integer used to distinguish all edges explicitly. @@ -164,23 +159,21 @@ - Integer used to distinguish faces explicitly. + Integer used to distinguish all faces explicitly. - + Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + 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 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. + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -189,7 +182,7 @@ - The edges are stored as a pairs of vertex identifier values. + The edges are stored as pairs of vertex identifier. @@ -198,7 +191,7 @@ - Array of identifiers from vertices which describe each face. + 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 @@ -207,7 +200,7 @@ Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -216,18 +209,23 @@ - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that 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 twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + 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: diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,63 +41,53 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Computational geometry description of a set of hexahedra in Euclidean space. - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. This class can also be used to describe cuboids or cubes, axis-aligned or not. The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + applied scientists and computational geometry experts an approach whereby + different specific views can be implemented using the same base class: - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. + * 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 the hexahedra is offered which serve different computational + 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. - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. + As a specialization of the :ref:`NXcg_primitive_set` 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 especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). + 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 codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries + 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 - tight fitting box about an arbitrary object. In general such boxes are + tightly fitting box about an arbitrary object. In general, such boxes are rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. + exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. + Qualifier for the shape of each hexahedron. @@ -105,9 +96,9 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. + Qualifier 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. @@ -115,8 +106,11 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific 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. @@ -124,31 +118,24 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific coordinate system. + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. - + - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + Volume of each hexahedron. - - - - - - - + - Total area (of all six faces) of each hexahedron. + Total (surface) area (of all six faces) of each hexahedron. @@ -176,64 +163,31 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Only to be used if is_box is present. In this case, this field describes whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. + axes of the coordinate system. - - + - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. + Combined storage of all primitives of all hexahedra. - - + - Disentangled representations of the mesh of specific hexahedra. + Individual storage of each hexahedron. - - + - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each hexahedron as a graph. diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 4cc765fd8..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,151 +33,74 @@ - Computational geometry description of a set of parallelograms in Euclidean space. + Computational geometry description of a set of parallelograms. - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + 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: - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. + * 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 we would like to specify the polygon - which is parallelogram represents. + * 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. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. + Parallelograms 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. - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. + 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_set` for the generalization in 3D. An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries + 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 - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. + 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. - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - + - Qualifier often used to describe the length of an edge within - a specific coordinate system. + To specify which parallelogram is a rectangle. - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. + 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. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - + - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. + Combined storage of all primitives of all parallelograms. - - + - Disentangled representations of the mesh of specific parallelograms. + Individual storage of each parallelogram. - + diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index e5c351839..bea36a1a9 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 1. + The dimensionality. @@ -38,61 +38,50 @@ - Computational geometry description of a set of points in Euclidean space. + Computational geometry description of a set of points. - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. + 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_set` instance which specifies the + points' locations. + + This is a frequent situation in experiments and computer simulations, where + positions of points are taken at the same point in time (real time or + simulated physical time). Thereby, the storage of redundant time stamp + information per point is considered as obsolete. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - + - Integer used to distinguish points for explicit indexing. + Coordinates of the points. - + + - + - The array of point coordinates. + (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. - + - - + - The optional array of time for each vertex. + ISO8601 with local time zone offset for each point. - + - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. + ISO8601 with local time zone offset that serves as the reference + for values in the field time. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index 4969f2e83..6f6cf68e6 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -52,7 +52,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Computational geometry description of a set of polygons in Euclidean space. - Polygons are related are specialized polylines: + 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. @@ -65,63 +65,40 @@ somewhat redundant as there is NXoff_geometry but easier to understand As three-dimensional objects, a set of polygons can be used to define the hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own + the specific :ref:`NXcg_polyhedron_set` 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_set to describe such even more - complex primitives. + complex primitives instead of abusing this base class for such purposes. - - - - - - - - - + - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + The total number of vertices in the set. - + + - Integer used to distinguish polygons for explicit indexing. + Combined storage of all primitives of all polygons. - - - - - - + + - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. + Individual storage of the mesh of each polygon. - - - - - - - - - - + + + Individual storage of each polygon as a graph. + + + - The accumulated length of the polygon edge. + For each polygon its accumulated length along its edges. @@ -129,7 +106,8 @@ properties of the polygon primitives--> - Array of interior angles. There are many values per polygon as number_of_vertices. + 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. @@ -150,78 +128,4 @@ properties of the polygon primitives--> - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index e3a6e99fe..af373d821 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -52,56 +53,21 @@ for clean graph-based descriptions of polyhedra.--> - Computational geometry description of a polyhedra in Euclidean space. + Computational geometry description of a set of polyhedra in Euclidean space. - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. + 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 more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. + 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_set`. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - + The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. + are counted for each polyhedron. @@ -109,86 +75,40 @@ for clean graph-based descriptions of polyhedra.--> - Area of each of the four triangular faces of each tetrahedron. + Area of each of faces. - + The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. + are counterd for each polyhedron. - Length of each edge of each tetrahedron. + Length of each edge. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. + Combined storage of all primitives of all polyhedra. - - + - Disentangled representations of the mesh of specific polyhedron. + Individual storage of each polyhedron. - - + - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each polygon as a graph. - diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..898a56acd 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..bc8b3e301 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,57 +33,13 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Computational geometry description of a set of tetrahedra in Euclidean space. + Computational geometry description of a set of tetrahedra. - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most + Among hexahedral elements, tetrahedral elements are one of the most frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. + objects in continuum-field simulations. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - Area of each of the four triangular faces of each tetrahedron. @@ -107,69 +58,29 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - + Interior angle values for each tetrahedron. + The quadruplet of angles is a sequence following the order of the vertices. + The angle is the angle at the specific vertex. + + The sequence of the vertices follows their definition in tetrahedra. +detailed mesh-based representation--> - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe + Combined storage of all primitives of all tetrahedra. - - + - Disentangled representations of the mesh of specific tetrahedra. + Individual storage of each tetrahedron. - - + - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each tetrahedron as a graph. diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..092b43c08 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,61 +43,39 @@ - Computational geometry description of a set of triangles in Euclidean space. + Computational geometry description of a set of triangles. - - - - + - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Number of unique vertices in the triangle set. - + - Integer used to distinguish triangles for explicit indexing. + 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. - - - - - - + + - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. + 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. - - - - - - - - - - - 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. + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. @@ -106,27 +84,14 @@ properties of 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. + 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. - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index e5f40c95a..000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. - - - diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml deleted file mode 100644 index 5ec33932b..000000000 --- a/base_classes/NXfabrication.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 9f38b2d7b..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Component of an instrument to store or place objects and specimens. + Computer science description of a memory in a memory system. - + + + Qualifier for the type of random access memory. + + + + - Given name/alias. + Total amount of data which the medium can hold. - + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From cb640072dbd90ebcb5a2eb2e1d31995d6b00db01 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 027/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_ellipsoid_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_hexahedron_set.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_parallelogram_set.nxdl.xml | 2 +- base_classes/NXcg_point_set.nxdl.xml | 2 +- base_classes/NXcg_polygon_set.nxdl.xml | 2 +- base_classes/NXcg_polyhedron_set.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 2 +- base_classes/NXcg_tetrahedron_set.nxdl.xml | 2 +- base_classes/NXcg_triangle_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 40 + .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXfabrication.nxdl.xml | 48 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXpump.nxdl.xml | 43 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 70 files changed, 8887 insertions(+), 135 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (51%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml index e2b247079..76322751e 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 51% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index 0034919dd..1f940f079 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Details about processing steps. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - - - + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 000000000..9f38b2d7b --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 53937d32d574708a521c04df524b4181e4ff0bf0 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 028/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 ++-- base_classes/NXcg_cylinder_set.nxdl.xml | 4 ++-- base_classes/NXcg_ellipsoid_set.nxdl.xml | 4 ++-- base_classes/NXcg_face_list_data_structure.nxdl.xml | 4 ++-- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 ++-- base_classes/NXcg_grid.nxdl.xml | 4 ++-- base_classes/NXcg_half_edge_data_structure.nxdl.xml | 4 ++-- base_classes/NXcg_hexahedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_marching_cubes.nxdl.xml | 4 ++-- base_classes/NXcg_parallelogram_set.nxdl.xml | 4 ++-- base_classes/NXcg_point_set.nxdl.xml | 4 ++-- base_classes/NXcg_polygon_set.nxdl.xml | 4 ++-- base_classes/NXcg_polyhedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_polyline_set.nxdl.xml | 4 ++-- base_classes/NXcg_roi_set.nxdl.xml | 4 ++-- base_classes/NXcg_sphere_set.nxdl.xml | 4 ++-- base_classes/NXcg_tetrahedron_set.nxdl.xml | 4 ++-- base_classes/NXcg_triangle_set.nxdl.xml | 4 ++-- base_classes/NXcg_triangulated_surface_mesh.nxdl.xml | 4 ++-- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 ++-- contributed_definitions/NXaberration.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model_ceos.nxdl.xml | 4 ++-- contributed_definitions/NXaberration_model_nion.nxdl.xml | 4 ++-- contributed_definitions/NXaperture_em.nxdl.xml | 4 ++-- contributed_definitions/NXapm.nxdl.xml | 4 ++-- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 ++-- contributed_definitions/NXcalibration.nxdl.xml | 4 ++-- contributed_definitions/NXcg_primitive_set.nxdl.xml | 4 ++-- contributed_definitions/NXchamber.nxdl.xml | 4 ++-- contributed_definitions/NXcoordinate_system.nxdl.xml | 4 ++-- contributed_definitions/NXcoordinate_system_set.nxdl.xml | 4 ++-- contributed_definitions/NXcorrector_cs.nxdl.xml | 4 ++-- contributed_definitions/NXcrystal_structure.nxdl.xml | 4 ++-- contributed_definitions/NXcs_computer.nxdl.xml | 4 ++-- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml | 4 ++-- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 ++-- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 ++-- contributed_definitions/NXcs_prng.nxdl.xml | 4 ++-- contributed_definitions/NXcs_profiling.nxdl.xml | 4 ++-- contributed_definitions/NXcs_profiling_event.nxdl.xml | 4 ++-- contributed_definitions/NXdeflector.nxdl.xml | 4 ++-- contributed_definitions/NXebeam_column.nxdl.xml | 4 ++-- contributed_definitions/NXelectronanalyser.nxdl.xml | 4 ++-- contributed_definitions/NXem.nxdl.xml | 4 ++-- contributed_definitions/NXem_base.nxdl.xml | 4 ++-- contributed_definitions/NXem_correlation.nxdl.xml | 4 ++-- contributed_definitions/NXem_ebsd.nxdl.xml | 4 ++-- contributed_definitions/NXem_eds.nxdl.xml | 4 ++-- contributed_definitions/NXem_eels.nxdl.xml | 4 ++-- contributed_definitions/NXem_img.nxdl.xml | 4 ++-- contributed_definitions/NXem_method.nxdl.xml | 4 ++-- contributed_definitions/NXem_msr.nxdl.xml | 4 ++-- contributed_definitions/NXem_sim.nxdl.xml | 4 ++-- contributed_definitions/NXenergydispersion.nxdl.xml | 4 ++-- contributed_definitions/NXevent_data_em.nxdl.xml | 4 ++-- contributed_definitions/NXevent_data_em_set.nxdl.xml | 4 ++-- contributed_definitions/NXfabrication.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_edge_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_node_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_root.nxdl.xml | 4 ++-- contributed_definitions/NXibeam_column.nxdl.xml | 4 ++-- contributed_definitions/NXimage_c_set.nxdl.xml | 4 ++-- contributed_definitions/NXimage_r_set.nxdl.xml | 4 ++-- contributed_definitions/NXimage_set.nxdl.xml | 4 ++-- contributed_definitions/NXion.nxdl.xml | 4 ++-- contributed_definitions/NXisocontour.nxdl.xml | 4 ++-- contributed_definitions/NXlens_em.nxdl.xml | 4 ++-- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- contributed_definitions/NXms.nxdl.xml | 4 ++-- contributed_definitions/NXms_feature_set.nxdl.xml | 4 ++-- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 ++-- contributed_definitions/NXms_score_results.nxdl.xml | 4 ++-- contributed_definitions/NXoptical_system_em.nxdl.xml | 4 ++-- contributed_definitions/NXpump.nxdl.xml | 4 ++-- contributed_definitions/NXroi.nxdl.xml | 4 ++-- contributed_definitions/NXscanbox_em.nxdl.xml | 4 ++-- contributed_definitions/NXspectrum_set.nxdl.xml | 4 ++-- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 83 files changed, 166 insertions(+), 166 deletions(-) diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index e22a677c1..f613be7ec 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 48610a31d..a452dc99f 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml index 8ea85fb98..e7569c628 100644 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ b/base_classes/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> 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. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml index bfb868c47..3709be64d 100644 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ b/base_classes/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,15 +83,13 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index c2190590d..5d8a15310 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index 95c157ce1..c70810832 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -46,9 +46,7 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -100,7 +98,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand For each polygon its accumulated length along its edges. - + @@ -112,7 +110,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -124,7 +122,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand * 1 - convex, * 2 - concave - + diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index b087b0c79..00eaec95a 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 8b1283474..58d4d5796 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index 509347c51..34c5d8ca7 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index 7d994eb3e..fe215dd3e 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> 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_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml index f613be7ec..e22a677c1 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/base_classes/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index a452dc99f..48610a31d 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml index e7569c628..8ea85fb98 100644 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ b/base_classes/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> 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. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml index 3709be64d..bfb868c47 100644 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ b/base_classes/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,13 +83,15 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml index 5d8a15310..c2190590d 100644 --- a/base_classes/NXcg_point_set.nxdl.xml +++ b/base_classes/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml index c70810832..95c157ce1 100644 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ b/base_classes/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -98,7 +100,7 @@ descriptors.--> For each polygon its accumulated length along its edges. - + @@ -110,7 +112,7 @@ descriptors.--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -122,7 +124,7 @@ descriptors.--> * 1 - convex, * 2 - concave - + diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml index 00eaec95a..b087b0c79 100644 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ b/base_classes/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 58d4d5796..8b1283474 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml index 34c5d8ca7..509347c51 100644 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ b/base_classes/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml index fe215dd3e..7d994eb3e 100644 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ b/base_classes/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> 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_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 6d72295599b8af0190c98ab8a88fa9530bc668b7 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 033/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 15000659ee95ca7baf67827ba87623cb4e86e4a8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 035/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 32 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + .../NXcs_gpu_obj.nxdl.xml | 27 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 6 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 95 files changed, 7209 insertions(+), 7943 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (67%) create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename {base_classes => contributed_definitions}/NXroi.nxdl.xml (95%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 57% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 98e6e02b2..6ce5370a3 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a (central) processing unit (C)PU of a computer. - - + - Principle type of the pump. + Given name of the CPU. Users should be as specific as possible. - - - - - - - + diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 67% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index bc6d4c291..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 95% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 94857e74c..b77834bb6 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 50% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 0034919dd..7ec26670c 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. + Container to hold NXevent_data_em instances of an electron microscope session. - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From cc80e84fe69730fc628b005665698d10675b055a Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 037/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 ++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 96 files changed, 359 insertions(+), 188 deletions(-) create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 2dfcbf37c3ef72c78cb42d31cc39f83ea4837178 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 042/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -60,90 +59,96 @@ duplicate of an NXoff_geometry ?--> - Computational geometry of primitives via a face-and-edge-list data structure. + Computational geometry description of geometric primitives via a face and edge list. - Primitives must neither be degenerated nor self-intersect but can differ in - their 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). + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. - Although this description is storage efficient it is not well suited for - topological analyses though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or very detailed specification demands. + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - Dimensionality of the primitives described. + Dimensionality. - + - 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. + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. - + - Number of edges 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 edges. - - - - + - Number of faces of the primitives. + Number of faces. - Integer offset whereby the identifier of the first member - of the vertices differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the edges differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the faces differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer identifier to distinguish all vertices explicitly. + Integer used to distinguish vertices explicitly. @@ -151,7 +156,7 @@ duplicate of an NXoff_geometry ?--> - Integer used to distinguish all edges explicitly. + Integer used to distinguish edges explicitly. @@ -159,21 +164,23 @@ duplicate of an NXoff_geometry ?--> - Integer used to distinguish all faces explicitly. + Integer used to distinguish faces explicitly. - + 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. + 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 each - vertex is stored even though many share the same positions. + 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. @@ -182,7 +189,7 @@ duplicate of an NXoff_geometry ?--> - The edges are stored as pairs of vertex identifier. + The edges are stored as a pairs of vertex identifier values. @@ -191,7 +198,7 @@ duplicate of an NXoff_geometry ?--> - The faces are stored as a concatenated array of vertex identifier tuples. + 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 @@ -200,7 +207,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. @@ -209,23 +216,18 @@ duplicate of an NXoff_geometry ?--> - 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 the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. - If true, indicates that no edge is stored 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. + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + Specifies for each face which winding order was used if any: diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml similarity index 71% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXchamber.nxdl.xml index 8353ca814..edf318e2a 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a graphic processing unit (GPU) of a computer. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Given name of the GPU. Users should be as specific as possible. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 9440d9b2c046dc35c4b0c8709b8f6604ca96f6ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 044/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_face_list_data_structure.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- .../NXcg_face_list_data_structure.nxdl.xml | 146 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 + ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 27 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 92 files changed, 4908 insertions(+), 9987 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (61%) rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,96 +60,90 @@ - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their 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). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + - Dimensionality. + Dimensionality of the primitives described. - + - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. + Number of 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. + 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. + Number of faces of the primitives. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer used to distinguish vertices explicitly. + Integer identifier to distinguish all vertices explicitly. @@ -156,7 +151,7 @@ - Integer used to distinguish edges explicitly. + Integer used to distinguish all edges explicitly. @@ -164,23 +159,21 @@ - Integer used to distinguish faces explicitly. + Integer used to distinguish all faces explicitly. - + Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + 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 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. + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -189,7 +182,7 @@ - The edges are stored as a pairs of vertex identifier values. + The edges are stored as pairs of vertex identifier. @@ -198,7 +191,7 @@ - Array of identifiers from vertices which describe each face. + 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 @@ -207,7 +200,7 @@ Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -216,18 +209,23 @@ - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that 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 twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + 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: diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml new file mode 100644 index 000000000..6ce5370a3 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a (central) processing unit (C)PU of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index e5f40c95a..3c5b6c26a 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a graphic processing unit (GPU) of a computer. - + + + Given name of the GPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From d68e489f3f64e43b8b897eeef88b66c24357c679 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 045/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + .../NXpump.nxdl.xml | 41 +- contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 61 files changed, 8786 insertions(+), 177 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXpump.nxdl.xml (53%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 53% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index aaad75e98..9f38b2d7b 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Device to reduce an atmosphere to a controlled remaining pressure level. - + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Principle type of the pump. - - - 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/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From c180ae0530594a8c8edce9ba2f3571f3120bfab1 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 046/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++++++++++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 84 files changed, 217 insertions(+), 166 deletions(-) create mode 100644 contributed_definitions/NXfabrication.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 48610a31d..a452dc99f 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 1c7bf6dc9..96c2d7123 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml index aff5c9b71..7e9d834b8 100644 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -70,6 +70,7 @@ + Description of the type of the detector. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/base_classes/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 59f5cffc0..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index d0c1d1809..000000000 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e445ff1e7..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 93b35cfef..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index abc88b051..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index d70836aee..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index d1fece068..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 97f1ebd1a..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 972ed6080..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index e9bd12b89..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index d42af5a47..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 5f42ead9bc93e4bdafe41b425a04eac56c37ceed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 050/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2034 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 12 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 20 +- .../NXcg_half_edge_data_structure.nxdl.xml | 26 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 12 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 10 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 165 ++ .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 10 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ .../NXms_odf_set.nxdl.xml | 32 +- contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 4 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 95 files changed, 7357 insertions(+), 7956 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXms_odf_set.nxdl.xml (53%) create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index ad33f94aa..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2034 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..260f16e1b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -2,9 +2,9 @@ even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 4ffc77ba8..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 9d674f6b2..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index e3c52b3ef..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 000000000..38a448a0e --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml similarity index 53% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXms_odf_set.nxdl.xml index 98e6e02b2..d41a609a8 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. - - - - Principle type of the pump. - - - - - - - - - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 5a1b0b8678be18a414b12a6cfe3c256f79def3ff Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 051/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXpump.nxdl.xml | 43 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 68 files changed, 8542 insertions(+), 177 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index bedba8b6f..0b1f581a8 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 000000000..9f38b2d7b --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From e7016522059d48d3c3dee8f59433dfcd697e222f Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 052/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 365 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml new file mode 100644 index 000000000..a57b1af0d --- /dev/null +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -0,0 +1,166 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + From b90ea5b57a1e994d97e144c3c5d43b92357d38fd Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:27:41 +0100 Subject: [PATCH 054/198] Recompiled NXDLs from YAML using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 6 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 389 ------------------ .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 144 ------- contributed_definitions/NXem_eels.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 247 ----------- .../NXimage_r_set.nxdl.xml | 100 ----- .../NXimage_r_set_diff.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 4 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 26 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 12 +- contributed_definitions/NXms_pf.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 42 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 8 +- .../NXsimilarity_grouping.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 49 files changed, 152 insertions(+), 1046 deletions(-) delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_eds.nxdl.xml delete mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index c00dfc240..e5e5e8860 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 95f0e8c41..a39efa0eb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -63,7 +63,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -72,7 +72,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 38e40b323bc78f1de700d1134521621ac201248b Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 057/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :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 diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 921663cef..21ccde167 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -192,9 +192,9 @@ used algorithm. Dictionary-based alternatives are emerging.--> - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. + of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ Integer which specifies the first index to be used for distinguishing features. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate if the diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..ae4014c48 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -186,7 +186,7 @@ ONE DIMENSIONAL FEATURES--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. @@ -331,7 +331,7 @@ properties, descriptors--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. @@ -384,7 +384,7 @@ i) triplet of interface identifier--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0c589ebd6 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -376,7 +376,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 586929596..8f7eeb911 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -56,7 +56,7 @@ NXcg_primitive_set(NXobject): Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :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 diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index 796ac83d3..421d336ba 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -115,9 +115,9 @@ NXcrystal_structure(NXobject): dim: (n_pos,) atom_type(NX_UINT): doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. + of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) `_ unit: NX_UNITLESS dim: (n_pos,) diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml index bd6825bac..050ae08d0 100644 --- a/contributed_definitions/nyaml/NXms_recon.yaml +++ b/contributed_definitions/nyaml/NXms_recon.yaml @@ -123,7 +123,7 @@ NXms_recon(NXobject): Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. unit: NX_UNITLESS crystal_identifier(NX_INT): doc: | @@ -226,7 +226,7 @@ NXms_recon(NXobject): Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. unit: NX_UNITLESS interface_identifier(NX_INT): doc: | @@ -268,7 +268,7 @@ NXms_recon(NXobject): Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. unit: NX_UNITLESS triple_point_identifier(NX_INT): doc: | From c9c29302e15e339e6e63af776d45b21528819f44 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 30 Aug 2024 11:06:46 +0200 Subject: [PATCH 059/198] Clarified issues with depends_on, fixed typo pID for pfID in NXem_ebsd # Conflicts: # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/nyaml/NXapm_hit_finding.yaml # contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml --- .../NXcg_half_edge_data_structure.nxdl.xml | 15 ++------------- base_classes/NXcg_polyline_set.nxdl.xml | 7 ------- .../NXcg_primitive_set.nxdl.xml | 8 ++++---- .../nyaml/NXcg_primitive_set.yaml | 5 ++--- contributed_definitions/nyaml/NXem_eds.yaml | 3 ++- 5 files changed, 10 insertions(+), 28 deletions(-) diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..759e30943 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -54,17 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - @@ -187,7 +176,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..f57d0c53f 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,6 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - - - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. - - The total number of vertices that have different positions. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index bcdbab8a6..034216a3e 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 8f7eeb911..7a8466b06 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -36,10 +36,9 @@ NXcg_primitive_set(NXobject): # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. dimensionality(NX_POSINT): doc: | The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 9a5a97fcd..e9d15f5b0 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -6,6 +6,7 @@ doc: | # 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_p: Number of scan points n_y: | @@ -13,7 +14,7 @@ symbols: n_x: | Number of pixel along the x direction, the fast direction n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | From e54306e26123f63e50e71dba534d219a962a3cb7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 060/198] move new definitions to application and base_classes # Conflicts: # applications/NXellipsometry.nxdl.xml # applications/NXmpes_arpes.nxdl.xml # applications/NXoptical_spectroscopy.nxdl.xml # applications/NXraman.nxdl.xml # applications/NXxps.nxdl.xml # applications/xps/xps_cs.png # base_classes/NXactivity.nxdl.xml # base_classes/NXactuator.nxdl.xml # base_classes/NXapm_charge_state_analysis.nxdl.xml # base_classes/NXapm_hit_finding.nxdl.xml # base_classes/NXapm_msr.nxdl.xml # base_classes/NXapm_ranging.nxdl.xml # base_classes/NXapm_reconstruction.nxdl.xml # base_classes/NXapm_sim.nxdl.xml # base_classes/NXapm_volt_and_bowl.nxdl.xml # base_classes/NXbeam_device.nxdl.xml # base_classes/NXbeam_transfer_matrix_table.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_face_list_data_structure.nxdl.xml # base_classes/NXcg_primitive_set.nxdl.xml # base_classes/NXchemical_process.nxdl.xml # base_classes/NXcircuit.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXcomponent.nxdl.xml # base_classes/NXdata_mpes.nxdl.xml # base_classes/NXdata_mpes_detector.nxdl.xml # base_classes/NXelectron_level.nxdl.xml # base_classes/NXem_eds.nxdl.xml # base_classes/NXevent_data_apm.nxdl.xml # base_classes/NXevent_data_apm_set.nxdl.xml # base_classes/NXfit.nxdl.xml # base_classes/NXfit_background.nxdl.xml # base_classes/NXfit_function.nxdl.xml # base_classes/NXfit_parameter.nxdl.xml # base_classes/NXhistory.nxdl.xml # base_classes/NXidentifier.nxdl.xml # base_classes/NXmanipulator.nxdl.xml # base_classes/NXopt_window.nxdl.xml # base_classes/NXphysical_process.nxdl.xml # base_classes/NXprocess_mpes.nxdl.xml # base_classes/NXresolution.nxdl.xml # base_classes/NXrotation_set.nxdl.xml # base_classes/NXsample_component_set.nxdl.xml # base_classes/NXserialized.nxdl.xml # base_classes/NXsingle_crystal.nxdl.xml # base_classes/NXspindispersion.nxdl.xml # base_classes/NXsubstance.nxdl.xml # base_classes/NXunit_cell.nxdl.xml # contributed_definitions/NXactivity.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXcomponent.nxdl.xml # contributed_definitions/NXcs_cpu_obj.nxdl.xml # contributed_definitions/NXcs_cpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_mm_obj.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXfit_function.nxdl.xml # contributed_definitions/NXfit_parameter.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXunit_cell.nxdl.xml # contributed_definitions/nyaml/NXcg_primitive_set.yaml # contributed_definitions/nyaml/NXcoordinate_system.yaml # contributed_definitions/nyaml/NXcrystal_structure.yaml # contributed_definitions/nyaml/NXem_correlation.yaml # contributed_definitions/nyaml/NXem_eds.yaml # contributed_definitions/nyaml/NXem_eels.yaml # contributed_definitions/nyaml/NXem_img.yaml # contributed_definitions/nyaml/NXem_method.yaml # contributed_definitions/nyaml/NXem_msr.yaml # contributed_definitions/nyaml/NXem_sim.yaml # contributed_definitions/nyaml/NXroi.yaml --- .../NXapm.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXaberration.nxdl.xml | 0 base_classes/NXcg_cylinder_set.nxdl.xml | 144 ++++--- .../NXcg_face_list_data_structure.nxdl.xml | 164 ++++---- base_classes/NXcg_primitive_set.nxdl.xml | 30 +- .../NXchamber.nxdl.xml | 0 .../NXcoordinate_system.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 .../NXcrystal_structure.nxdl.xml | 0 .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXem_correlation.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_eels.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXfabrication.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXprogram.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXregistration.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXaperture_em.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 111 ------ .../NXcg_cylinder_set.nxdl.xml | 165 -------- .../NXcg_ellipsoid_set.nxdl.xml | 135 ------- .../NXcg_face_list_data_structure.nxdl.xml | 243 ------------ .../NXcg_hexahedron_set.nxdl.xml | 239 ----------- .../NXcg_parallelogram_set.nxdl.xml | 183 --------- .../NXcg_point_set.nxdl.xml | 98 ----- .../NXcg_polygon_set.nxdl.xml | 227 ----------- .../NXcg_polyhedron_set.nxdl.xml | 194 --------- .../NXcg_primitive_set.nxdl.xml | 212 ---------- .../NXcg_sphere_set.nxdl.xml | 121 ------ .../NXcg_tetrahedron_set.nxdl.xml | 175 --------- .../NXcg_triangle_set.nxdl.xml | 132 ------- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 -- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 --- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 --- .../NXelectronanalyser.nxdl.xml | 157 -------- contributed_definitions/NXem_msr.nxdl.xml | 97 ----- contributed_definitions/NXem_sim.nxdl.xml | 60 --- .../NXenergydispersion.nxdl.xml | 90 ----- .../NXinteraction_vol_em.nxdl.xml | 37 -- contributed_definitions/NXmpes.nxdl.xml | 371 ------------------ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 -- contributed_definitions/NXpulser_apm.nxdl.xml | 166 -------- contributed_definitions/NXreflectron.nxdl.xml | 56 --- .../nyaml/NXcg_primitive_set.yaml | 135 ------- .../nyaml/NXcoordinate_system.yaml | 86 ---- .../nyaml/NXcrystal_structure.yaml | 178 --------- .../nyaml/NXem_correlation.yaml | 191 --------- contributed_definitions/nyaml/NXem_eds.yaml | 81 ---- contributed_definitions/nyaml/NXem_eels.yaml | 39 -- contributed_definitions/nyaml/NXem_img.yaml | 25 -- .../nyaml/NXem_method.yaml | 21 - contributed_definitions/nyaml/NXem_msr.yaml | 63 --- contributed_definitions/nyaml/NXem_sim.yaml | 34 -- contributed_definitions/nyaml/NXroi.yaml | 9 - 77 files changed, 184 insertions(+), 4464 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcrystal_structure.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_correlation.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_eels.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfabrication.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXprogram.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXregistration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml delete mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml delete mode 100644 contributed_definitions/NXem_msr.nxdl.xml delete mode 100644 contributed_definitions/NXem_sim.nxdl.xml delete mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml delete mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml delete mode 100644 contributed_definitions/NXreflectron.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.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_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5e5e8860 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + 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. + The cardinality of the set, i.e. the number of cylinders or cones. - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders in Euclidean space. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. - + + + + + + + - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - + + + + Integer used to distinguish members for explicit indexing. + + - - - + - Radius of the cylinder if all have the same radius. + The geometric center of each member. + + + + - + - Radii of the cylinder. + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. - + + + + + + + + - + - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + - + - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + - Lateral surface area + Interior volume of each cylinder - + - + - Area of the upper cap of each cylinder. + Lateral surface area - + - + - Area of the lower cap of each cylinder. + Area of the upper and the lower cap of each cylinder respectively. - + + - + - Sum of upper and lower cap areas and lateral surface area - of each cylinder. + Cap and lateral surface area for each cylinder. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index a452dc99f..ea8faee3e 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -60,138 +59,146 @@ duplicate of an NXoff_geometry ?--> - Computational geometry of primitives via a face-and-edge-list data structure. + Computational geometry description of geometric primitives via a face and edge list. - Primitives must neither be degenerated nor self-intersect but can differ in - their 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). + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. - Although this description is storage efficient it is not well suited for - topological analyses though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or very detailed specification demands. + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - Dimensionality of the primitives described. + Dimensionality. - + - 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. + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. - + - + - Number of edges 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 edges. - - - - + - Number of faces of the primitives. + Number of faces. - Integer offset whereby the identifier of the first member - of the vertices differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the edges differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer offset whereby the identifier of the first member - of the faces differs from zero. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - Integer identifier to distinguish all vertices explicitly. + Integer used to distinguish vertices explicitly. - + - Integer used to distinguish all edges explicitly. + Integer used to distinguish edges explicitly. - + - Integer used to distinguish all faces explicitly. + Integer used to distinguish faces explicitly. - + - + 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. + 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 each - vertex is stored even though many share the same positions. + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. - + - The edges are stored as pairs of vertex identifier. + The edges are stored as a pairs of vertex identifier values. - + - The faces are stored as a concatenated array of vertex identifier tuples. + 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 @@ -200,32 +207,27 @@ duplicate of an NXoff_geometry ?--> 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}]`. + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - + - If true, indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted more - than once. + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. - If true, indicates that no edge is stored 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. + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + Specifies for each face which winding order was used if any: @@ -234,7 +236,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml index 93b35cfef..034216a3e 100644 --- a/base_classes/NXcg_primitive_set.nxdl.xml +++ b/base_classes/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. @@ -94,7 +94,7 @@ to enable an instantiation of the actual geometric primitives--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :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 @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system.nxdl.xml rename to base_classes/NXcoordinate_system.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcrystal_structure.nxdl.xml rename to base_classes/NXcrystal_structure.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_correlation.nxdl.xml rename to base_classes/NXem_correlation.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eels.nxdl.xml rename to base_classes/NXem_eels.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index e5e5e8860..000000000 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 034216a3e..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 7a8466b06..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,135 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 421d336ba..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index e9d15f5b0..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,81 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 712bde414edfa2cbae7c8625d70e10b2903fb314 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 061/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_face_list_data_structure.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_recon.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 128 +- .../NXcg_face_list_data_structure.nxdl.xml | 146 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 21 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 13 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 27 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 12 +- .../NXms_feature_set.nxdl.xml | 2 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 24 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXms_recon.yaml | 315 --- contributed_definitions/nyaml/NXroi.yaml | 9 + 93 files changed, 4948 insertions(+), 10380 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (67%) rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXms_recon.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + 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 cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius 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 lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index ea8faee3e..54cce1279 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,96 +60,90 @@ - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their 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). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + - Dimensionality. + Dimensionality of the primitives described. - + - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. + Number of 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. + 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. + Number of faces of the primitives. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer used to distinguish vertices explicitly. + Integer identifier to distinguish all vertices explicitly. @@ -156,7 +151,7 @@ - Integer used to distinguish edges explicitly. + Integer used to distinguish all edges explicitly. @@ -164,23 +159,21 @@ - Integer used to distinguish faces explicitly. + Integer used to distinguish all faces explicitly. - + Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + 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 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. + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -189,7 +182,7 @@ - The edges are stored as a pairs of vertex identifier values. + The edges are stored as pairs of vertex identifier. @@ -198,7 +191,7 @@ - Array of identifiers from vertices which describe each face. + 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 @@ -207,7 +200,7 @@ Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -216,18 +209,23 @@ - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that 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 twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + 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: diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,6 +54,17 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + Dimensionality of the primitives described. + + @@ -176,7 +187,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 4cc765fd8..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 67% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index bc6d4c291..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index f49471a84..0e41c38d4 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -338,7 +336,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + interval [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 2da74d128..326d8cc54 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -162,7 +162,7 @@ end up as links--> Integer which specifies the first index to be used for distinguishing features. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + interval [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate if the diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index ae4014c48..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 0c589ebd6..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -376,7 +374,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + interval [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml deleted file mode 100644 index 050ae08d0..000000000 --- a/contributed_definitions/nyaml/NXms_recon.yaml +++ /dev/null @@ -1,315 +0,0 @@ -# position would need another depends_on the specific coordinate system used, currently we assume McStas -# roi1/ebsd/microstructure1 -category: base -doc: | - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - # in so-called linear intercept analysis we observe - # one-dimensional sections of either projections (see below) - # or true one-dimensional cuts across a volume of material - # n_icept: | - # The number of linear intercepts defined. - # n_c_one: | - # The number of crystal projections segmented by crossing (projected or real) interfaces - # n_i_one: | - # The number of crossings - # two-dimensional projections of characterized in reality three-dimensional objects - # using E. E. Underwood notation - # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" - n_c_two: | - The number of crystal projections. - n_i_two: | - The number of interface projections. - n_t_two: | - The number of assumed triple junction projections aka triple points. - # three-dimensional real objects, volumetrically characterized - # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions - n_c: | - The number of crystals. - n_i: | - The number of interfaces - n_t: | - The number of triple lines - n_q: | - The number of quadruple junctions. -type: group -NXms_recon(NXobject): - # as e.g. a result of one grain reconstruction with MTex or othe - # grain reconstruction software in commercial tools - # the idea is we may wish to run as many grain reconstructions as we want... - # add details about the processing - configuration(NXprocess): - doc: | - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - # maybe a depends_on what was the input however if the group is injected - # in an roi1/ebsd instance isnt this information implicit? - dimensionality(NX_POSINT): - doc: | - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - algorithm(NX_CHAR): - doc: | - Which algorithm is used to reconstruct the features. - enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] - disorientation_threshold(NX_NUMBER): - doc: | - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - unit: NX_ANGLE - # the result of running one grain reconstruction - # ms_feature_set1 - # we could also enumerate instances ms_feature_setID here because configuration - # may specify a range of different parameter resulting in multiple ms_feature_sets - # dimensionality(N) composed from NXms_feature_set base: - # controlled vocabulary of base class instances to be used to inform about the - # discretization of these features instances to discretize the features - # wherever possible the computational geometry specific instances whose - # purpose is only to support/represent the discretization of the features should - # be separated out from the materials engineering interpretation of what these - # features are, i.e. a grain that is measured with a 2d section ends up - # modelled as an projection of that real 3d grain object - # the model is discretized usign a polyline which models the location of the - # interface at the required here coarse-grained continuum picture - points(NXcg_point_set): - lines(NXcg_polyline_set): - surfaces(NXcg_triangle_set): - volumes(NXcg_polyhedron_set): - - # domain-specific, i.e. microstructural features - # ONE DIMENSIONAL FEATURES - - # TWO DIMENSIONAL FEATURES - crystal_projections(NXms_feature_set): - doc: | - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - \@discretization(NX_CHAR): - doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - number_of_crystals(NX_UINT): - doc: | - Number of crystals. - unit: NX_UNITLESS - crystal_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - crystal_identifier(NX_INT): - doc: | - Identifier used for crystals for explicit indexing. - unit: NX_UNITLESS - dim: (n_c_two,) - number_of_phases(NX_UINT): - doc: | - How many phases are distinguished - unit: NX_UNITLESS - phase_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - unit: NX_UNITLESS - phase_identifier(NX_INT): - # \@depends_on(NX_CHAR): - doc: | - Identifier used for phase for explicit indexing. - unit: NX_UNITLESS - dim: (n_c_two,) - # properties of crystal_projections aka grain properties - boundary_contact(NX_BOOLEAN): - doc: | - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - dim: (n_c_two,) - orientation_spread(NX_NUMBER): - doc: | - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - unit: NX_ANGLE - dim: (n_c_two,) - (NXrotation_set): - area(NX_NUMBER): - doc: | - Calibrated area of surrounded by the polyline about each crystal. - unit: NX_AREA - dim: (n_c_two,) - interface_projections(NXms_feature_set): - # grain boundaries have a network of line-like defects, its explicit description - # often generates unnecessary information duplication and cluttering, - # therefore here a compact and suggestion how to store such data - doc: | - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - \@discretization(NX_CHAR): - doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - # topology - # i) Set of pair of crystals sharing an interface - crystals(NX_INT): - doc: | - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): - doc: | - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - # ii) Set of pair of topologically connected triple points - triple_points(NX_INT): - doc: | - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): - doc: | - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - # alternatively which polyline of adjoining interfaces - # properties, descriptors - length(NX_NUMBER): - doc: | - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - unit: NX_LENGTH - dim: (n_i_two,) - interface_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - interface_identifier(NX_INT): - doc: | - Identifier for each interface using explicit indexing. - unit: NX_UNITLESS - dim: (n_i_two,) - triple_line_projections(NXms_feature_set): - # only for 2D, quad junction is the equivalent for 3D is not a triple_line - # four alternative descriptors with different strength to specify spatial - # or logical information about the triple junction feature set. - # the explicit description often generating unnecessary information duplication - doc: | - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - \@discretization(NX_CHAR): - doc: | - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - # another view to describe a triple junction is via its topology/connection expressed either via - # i) triplet of interface identifier - number_of_triple_points(NX_UINT): - doc: | - Number of triple points. - unit: NX_UNITLESS - triple_point_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - triple_point_identifier(NX_INT): - doc: | - Identifier for each triple point using explicit indexing. - unit: NX_UNITLESS - dim: (n_t_two,) - location(NX_INT): - doc: | - Set of triple point identifiers. - unit: NX_UNITLESS - dim: (n_t_two,) - \@depends_on(NX_CHAR): - doc: | - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - interfaces(NX_INT): # aka topology or interfaces - doc: | - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): - doc: | - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - # ii) a triplet of line segment identifier whereby the point-like features - # is assumed discretized via three polylines representing interfaces - polylines(NX_INT): - doc: | - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): - doc: | - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - # the difference in the interpretation of interfaces and polylines - # is that the interface resolves interface (e.g. phase boundary names) - # while polylines resolves segments within the set of named geometric primitive - # instances! - # add all sort of other qualitative or quantitive descriptors (triple junction - # energy, volume etc), i.e properties of that triple point diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 95db29180c9c64658ebe23935c532c5df45aff00 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 062/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 60 files changed, 8785 insertions(+), 127 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From f11473f9904629dc30fa6461b5a6801c91d35ede Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 063/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 85 files changed, 211 insertions(+), 168 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 48610a31d..a452dc99f 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 1c7bf6dc9..96c2d7123 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index a452dc99f..48610a31d 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> 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}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 52b890e1d1fe54c9860fb2c977c86668e1016453 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 068/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -75,17 +75,6 @@ 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 very detailed specification demands. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..759e30943 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -54,17 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - @@ -187,7 +176,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..f57d0c53f 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,6 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - - - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. - - The total number of vertices that have different positions. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..c3636c6b3 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 586929596..68b87e47e 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -36,10 +36,9 @@ NXcg_primitive_set(NXobject): # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. dimensionality(NX_POSINT): doc: | The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 9a5a97fcd..e9d15f5b0 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -6,6 +6,7 @@ doc: | # 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_p: Number of scan points n_y: | @@ -13,7 +14,7 @@ symbols: n_x: | Number of pixel along the x direction, the fast direction n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | From ec10c7d9bacfc1f4912c1c2b430649af2dd1692d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 070/198] move new definitions to application and base_classes # Conflicts: # applications/NXellipsometry.nxdl.xml # applications/NXmpes_arpes.nxdl.xml # applications/NXoptical_spectroscopy.nxdl.xml # applications/NXraman.nxdl.xml # applications/NXxps.nxdl.xml # applications/xps/xps_cs.png # base_classes/NXactivity.nxdl.xml # base_classes/NXactuator.nxdl.xml # base_classes/NXapm_charge_state_analysis.nxdl.xml # base_classes/NXapm_hit_finding.nxdl.xml # base_classes/NXapm_msr.nxdl.xml # base_classes/NXapm_ranging.nxdl.xml # base_classes/NXapm_reconstruction.nxdl.xml # base_classes/NXapm_sim.nxdl.xml # base_classes/NXapm_volt_and_bowl.nxdl.xml # base_classes/NXbeam_device.nxdl.xml # base_classes/NXbeam_transfer_matrix_table.nxdl.xml # base_classes/NXchemical_process.nxdl.xml # base_classes/NXcircuit.nxdl.xml # base_classes/NXcomponent.nxdl.xml # base_classes/NXcrystal_structure.nxdl.xml # base_classes/NXdata_mpes.nxdl.xml # base_classes/NXdata_mpes_detector.nxdl.xml # base_classes/NXelectron_level.nxdl.xml # base_classes/NXem_eds.nxdl.xml # base_classes/NXevent_data_apm.nxdl.xml # base_classes/NXevent_data_apm_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXfit.nxdl.xml # base_classes/NXfit_background.nxdl.xml # base_classes/NXfit_function.nxdl.xml # base_classes/NXfit_parameter.nxdl.xml # base_classes/NXhistory.nxdl.xml # base_classes/NXidentifier.nxdl.xml # base_classes/NXmanipulator.nxdl.xml # base_classes/NXopt_window.nxdl.xml # base_classes/NXphysical_process.nxdl.xml # base_classes/NXprocess_mpes.nxdl.xml # base_classes/NXresolution.nxdl.xml # base_classes/NXrotation_set.nxdl.xml # base_classes/NXsample_component_set.nxdl.xml # base_classes/NXserialized.nxdl.xml # base_classes/NXsingle_crystal.nxdl.xml # base_classes/NXspindispersion.nxdl.xml # base_classes/NXsubstance.nxdl.xml # base_classes/NXunit_cell.nxdl.xml # contributed_definitions/NXactivity.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXcomponent.nxdl.xml # contributed_definitions/NXcs_cpu_obj.nxdl.xml # contributed_definitions/NXcs_cpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_mm_obj.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXfit_function.nxdl.xml # contributed_definitions/NXfit_parameter.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXunit_cell.nxdl.xml # contributed_definitions/nyaml/NXcg_primitive_set.yaml # contributed_definitions/nyaml/NXcoordinate_system.yaml # contributed_definitions/nyaml/NXcrystal_structure.yaml # contributed_definitions/nyaml/NXem_correlation.yaml # contributed_definitions/nyaml/NXem_eds.yaml # contributed_definitions/nyaml/NXem_eels.yaml # contributed_definitions/nyaml/NXem_img.yaml # contributed_definitions/nyaml/NXem_method.yaml # contributed_definitions/nyaml/NXem_msr.yaml # contributed_definitions/nyaml/NXem_sim.yaml # contributed_definitions/nyaml/NXroi.yaml --- .../NXapm.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXaberration.nxdl.xml | 0 .../NXchamber.nxdl.xml | 0 .../NXcollectioncolumn.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 base_classes/NXcrystal_structure.nxdl.xml | 280 ------------- .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXaperture_em.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 111 ------ .../NXcg_ellipsoid_set.nxdl.xml | 135 ------- .../NXcg_hexahedron_set.nxdl.xml | 239 ----------- .../NXcg_parallelogram_set.nxdl.xml | 183 --------- .../NXcg_point_set.nxdl.xml | 98 ----- .../NXcg_polygon_set.nxdl.xml | 227 ----------- .../NXcg_polyhedron_set.nxdl.xml | 194 --------- .../NXcg_primitive_set.nxdl.xml | 212 ---------- .../NXcg_sphere_set.nxdl.xml | 121 ------ .../NXcg_tetrahedron_set.nxdl.xml | 175 --------- .../NXcg_triangle_set.nxdl.xml | 132 ------- .../NXcoordinate_system.nxdl.xml | 143 ------- .../NXcrystal_structure.nxdl.xml | 280 ------------- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 -- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 --- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 --- .../NXelectronanalyser.nxdl.xml | 157 -------- .../NXem_correlation.nxdl.xml | 245 ------------ contributed_definitions/NXem_eels.nxdl.xml | 79 ---- contributed_definitions/NXem_msr.nxdl.xml | 97 ----- contributed_definitions/NXem_sim.nxdl.xml | 60 --- .../NXenergydispersion.nxdl.xml | 90 ----- .../NXinteraction_vol_em.nxdl.xml | 37 -- contributed_definitions/NXmpes.nxdl.xml | 371 ------------------ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 -- contributed_definitions/NXpulser_apm.nxdl.xml | 166 -------- contributed_definitions/NXreflectron.nxdl.xml | 56 --- .../nyaml/NXcg_primitive_set.yaml | 135 ------- .../nyaml/NXcoordinate_system.yaml | 86 ---- .../nyaml/NXcrystal_structure.yaml | 178 --------- .../nyaml/NXem_correlation.yaml | 191 --------- contributed_definitions/nyaml/NXem_eds.yaml | 81 ---- contributed_definitions/nyaml/NXem_eels.yaml | 39 -- contributed_definitions/nyaml/NXem_img.yaml | 25 -- .../nyaml/NXem_method.yaml | 21 - contributed_definitions/nyaml/NXem_msr.yaml | 63 --- contributed_definitions/nyaml/NXem_sim.yaml | 34 -- contributed_definitions/nyaml/NXroi.yaml | 9 - 71 files changed, 4 insertions(+), 4925 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcollectioncolumn.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) delete mode 100644 base_classes/NXcrystal_structure.nxdl.xml rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml delete mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml delete mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml delete mode 100644 contributed_definitions/NXem_correlation.nxdl.xml delete mode 100644 contributed_definitions/NXem_eels.nxdl.xml delete mode 100644 contributed_definitions/NXem_msr.nxdl.xml delete mode 100644 contributed_definitions/NXem_sim.nxdl.xml delete mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml delete mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml delete mode 100644 contributed_definitions/NXreflectron.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.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_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 21ccde167..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index c3636c6b3..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 68b87e47e..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,135 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index e9d15f5b0..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,81 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 13d88f2b1e7340ad29258e6281eeccf881d43796 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 071/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 21 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 13 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXms_recon.yaml | 315 +++ contributed_definitions/nyaml/NXroi.yaml | 9 + 96 files changed, 7534 insertions(+), 7983 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXms_recon.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,6 +54,17 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + Dimensionality of the primitives described. + + @@ -176,7 +187,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 4cc765fd8..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml new file mode 100644 index 000000000..bd6825bac --- /dev/null +++ b/contributed_definitions/nyaml/NXms_recon.yaml @@ -0,0 +1,315 @@ +# position would need another depends_on the specific coordinate system used, currently we assume McStas +# roi1/ebsd/microstructure1 +category: base +doc: | + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + # in so-called linear intercept analysis we observe + # one-dimensional sections of either projections (see below) + # or true one-dimensional cuts across a volume of material + # n_icept: | + # The number of linear intercepts defined. + # n_c_one: | + # The number of crystal projections segmented by crossing (projected or real) interfaces + # n_i_one: | + # The number of crossings + # two-dimensional projections of characterized in reality three-dimensional objects + # using E. E. Underwood notation + # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" + n_c_two: | + The number of crystal projections. + n_i_two: | + The number of interface projections. + n_t_two: | + The number of assumed triple junction projections aka triple points. + # three-dimensional real objects, volumetrically characterized + # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions + n_c: | + The number of crystals. + n_i: | + The number of interfaces + n_t: | + The number of triple lines + n_q: | + The number of quadruple junctions. +type: group +NXms_recon(NXobject): + # as e.g. a result of one grain reconstruction with MTex or othe + # grain reconstruction software in commercial tools + # the idea is we may wish to run as many grain reconstructions as we want... + # add details about the processing + configuration(NXprocess): + doc: | + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + # maybe a depends_on what was the input however if the group is injected + # in an roi1/ebsd instance isnt this information implicit? + dimensionality(NX_POSINT): + doc: | + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + algorithm(NX_CHAR): + doc: | + Which algorithm is used to reconstruct the features. + enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] + disorientation_threshold(NX_NUMBER): + doc: | + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + unit: NX_ANGLE + # the result of running one grain reconstruction + # ms_feature_set1 + # we could also enumerate instances ms_feature_setID here because configuration + # may specify a range of different parameter resulting in multiple ms_feature_sets + # dimensionality(N) composed from NXms_feature_set base: + # controlled vocabulary of base class instances to be used to inform about the + # discretization of these features instances to discretize the features + # wherever possible the computational geometry specific instances whose + # purpose is only to support/represent the discretization of the features should + # be separated out from the materials engineering interpretation of what these + # features are, i.e. a grain that is measured with a 2d section ends up + # modelled as an projection of that real 3d grain object + # the model is discretized usign a polyline which models the location of the + # interface at the required here coarse-grained continuum picture + points(NXcg_point_set): + lines(NXcg_polyline_set): + surfaces(NXcg_triangle_set): + volumes(NXcg_polyhedron_set): + + # domain-specific, i.e. microstructural features + # ONE DIMENSIONAL FEATURES + + # TWO DIMENSIONAL FEATURES + crystal_projections(NXms_feature_set): + doc: | + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + number_of_crystals(NX_UINT): + doc: | + Number of crystals. + unit: NX_UNITLESS + crystal_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + crystal_identifier(NX_INT): + doc: | + Identifier used for crystals for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + number_of_phases(NX_UINT): + doc: | + How many phases are distinguished + unit: NX_UNITLESS + phase_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + unit: NX_UNITLESS + phase_identifier(NX_INT): + # \@depends_on(NX_CHAR): + doc: | + Identifier used for phase for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + # properties of crystal_projections aka grain properties + boundary_contact(NX_BOOLEAN): + doc: | + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + dim: (n_c_two,) + orientation_spread(NX_NUMBER): + doc: | + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + unit: NX_ANGLE + dim: (n_c_two,) + (NXrotation_set): + area(NX_NUMBER): + doc: | + Calibrated area of surrounded by the polyline about each crystal. + unit: NX_AREA + dim: (n_c_two,) + interface_projections(NXms_feature_set): + # grain boundaries have a network of line-like defects, its explicit description + # often generates unnecessary information duplication and cluttering, + # therefore here a compact and suggestion how to store such data + doc: | + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + # topology + # i) Set of pair of crystals sharing an interface + crystals(NX_INT): + doc: | + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + # ii) Set of pair of topologically connected triple points + triple_points(NX_INT): + doc: | + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + # alternatively which polyline of adjoining interfaces + # properties, descriptors + length(NX_NUMBER): + doc: | + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + unit: NX_LENGTH + dim: (n_i_two,) + interface_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + interface_identifier(NX_INT): + doc: | + Identifier for each interface using explicit indexing. + unit: NX_UNITLESS + dim: (n_i_two,) + triple_line_projections(NXms_feature_set): + # only for 2D, quad junction is the equivalent for 3D is not a triple_line + # four alternative descriptors with different strength to specify spatial + # or logical information about the triple junction feature set. + # the explicit description often generating unnecessary information duplication + doc: | + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + \@discretization(NX_CHAR): + doc: | + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + # another view to describe a triple junction is via its topology/connection expressed either via + # i) triplet of interface identifier + number_of_triple_points(NX_UINT): + doc: | + Number of triple points. + unit: NX_UNITLESS + triple_point_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + unit: NX_UNITLESS + triple_point_identifier(NX_INT): + doc: | + Identifier for each triple point using explicit indexing. + unit: NX_UNITLESS + dim: (n_t_two,) + location(NX_INT): + doc: | + Set of triple point identifiers. + unit: NX_UNITLESS + dim: (n_t_two,) + \@depends_on(NX_CHAR): + doc: | + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + interfaces(NX_INT): # aka topology or interfaces + doc: | + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + # ii) a triplet of line segment identifier whereby the point-like features + # is assumed discretized via three polylines representing interfaces + polylines(NX_INT): + doc: | + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + # the difference in the interpretation of interfaces and polylines + # is that the interface resolves interface (e.g. phase boundary names) + # while polylines resolves segments within the set of named geometric primitive + # instances! + # add all sort of other qualitative or quantitive descriptors (triple junction + # energy, volume etc), i.e properties of that triple point diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From e46f0b13f94ded147fd135407b62fdbbf15ad4e4 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 072/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + .../NXpump.nxdl.xml | 41 +- contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8501 insertions(+), 228 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXpump.nxdl.xml (53%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 53% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index aaad75e98..9f38b2d7b 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Device to reduce an atmosphere to a controlled remaining pressure level. - + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Principle type of the pump. - - - 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/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 227dd233d3a04455b49ecfb142253a4139d56922 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 073/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 40 ++++++ .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 403 insertions(+), 184 deletions(-) create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0b1f581a8..a68436e9b 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 4fdabcf9359b1dc40050f8016f92ef7101b4e5dc Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 078/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From cb00a76d2f197b66aded1de38bf5f7d8b71fa9ba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 080/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 23 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 93 files changed, 5047 insertions(+), 9917 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (68%) rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 68% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index edf318e2a..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 2615623471f1300bdefee28c0ca5ec5962d0313f Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 081/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 46 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 40 + .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXfabrication.nxdl.xml | 48 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 61 files changed, 8851 insertions(+), 156 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (51%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - + The symbols used in the schema to specify e.g. dimensions of arrays. - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. + Computer science description of a system of coprocessor or graphics processors. - - - In the case that all spheres have the same radius. - - - + - In the case that spheres have different radius use this - instead of the radius field. + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. - - - - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index 5aebe0d78..58454a5e1 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 51% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index 0034919dd..1f940f079 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Details about processing steps. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - - - + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 191015603de27ccab5570c6d596dfd8f7109ec6c Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 082/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 85 files changed, 211 insertions(+), 168 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From c3466ff1aaa413273ad0d057b67c8c18d6f420e0 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 087/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + - Computer science description of a system of coprocessor or graphics processors. + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. - + + + - Granularizing at the socket level. + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From e045d40610e0ee0b477dd7980e3555487ce2aa10 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 089/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_sphere_set.nxdl.xml | 74 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ .../NXms_odf_set.nxdl.xml | 28 +- contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 94 files changed, 7057 insertions(+), 8016 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXms_odf_set.nxdl.xml (53%) create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml similarity index 53% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXms_odf_set.nxdl.xml index 9f38b2d7b..d41a609a8 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. - - - - Principle type of the pump. - - - - - - - - - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From b2079db7521baa6a371135ee59b7cc6fad7574da Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 090/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8486 insertions(+), 204 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 740651218461c4ba4a1f051f97476ec4db885072 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 091/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 40 ++++++ .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 ++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 96 files changed, 397 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0b1f581a8..a68436e9b 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 8b1283474..58d4d5796 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 58d4d5796..8b1283474 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From b3019b2c6cf1ded11c0c81877b87532bbbbe3c32 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 096/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 5c62f7974f06c2c24084b2a03c23124cb9d5cf3c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 098/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 23 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 92 files changed, 5051 insertions(+), 9925 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (68%) rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 68% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index edf318e2a..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From cb37e4164eb53652a7f8474bceedc2713b0cf714 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 099/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 38 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXfabrication.nxdl.xml | 48 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 60 files changed, 8808 insertions(+), 151 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (57%) create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (51%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - 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/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 51% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index 0034919dd..1f940f079 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Details about processing steps. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - - - + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 7a9233a83e13e0c9b01dccf727f47f587af0c8a8 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 100/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 84 files changed, 209 insertions(+), 166 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d64..434aa8373 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 434aa8373..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0fc68849d..f4e6577d5 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third entry beginning from entry 90 up to 99. - + From 1f7f852a88c0186b5440c0c9277edd414fe44df4 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 105/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_charge_state_analysis.nxdl.xml # contributed_definitions/NXapm_hit_finding.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXapm_ranging.nxdl.xml # contributed_definitions/NXapm_reconstruction.nxdl.xml # contributed_definitions/NXapm_volt_and_bowl.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXevent_data_apm.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpulser_apm.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXsimilarity_grouping.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXsubsampling_filter.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/NXsubsampling_filter.nxdl.xml | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d..000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - 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. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1be..000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 57cd3c083bccff58c9871aa44c77d6b937b1d252 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 107/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ .../NXms_odf_set.nxdl.xml | 28 +- contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 95 files changed, 7173 insertions(+), 7951 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXms_odf_set.nxdl.xml (53%) create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml similarity index 53% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXms_odf_set.nxdl.xml index 9f38b2d7b..d41a609a8 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. - - - - Principle type of the pump. - - - - - - - - - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From ec467cfa835b8db528d17cb4a776843d02fd4e52 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 108/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXpump.nxdl.xml | 43 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8543 insertions(+), 178 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index bedba8b6f..0b1f581a8 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 000000000..9f38b2d7b --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From f0ad47568a8bbb76db25e26065550e068d7bf238 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 109/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 365 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - Computational geometry description of the marching cubes algorithm. + Base class to detail the marching cubes (MC) algorithm. - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. + Documenting which specific version of MC was used helps with understanding + how robust the results are with respect to the topology of the triangulation. - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. + Metadata of the grid on which the here specified MC is operating. - + Reference to the specific implementation of marching cubes used. - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: + See for example the following papers for details about specific + MC implementations: * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. + + + + + Free text field in case a proper identifier is not available. diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml index 4a030c684..aeec36f24 100644 --- a/base_classes/NXpeak.nxdl.xml +++ b/base_classes/NXpeak.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,21 +33,21 @@ - Description of peaks, their functional form or measured support. + Base class for peaks, their functional form, and measured support. - + - Human-readable identifier to specify which concept/entity + Human-readable label which specifies which concept/entity the peak represents/identifies. - + Is the peak described analytically via a functional form or is it empirically defined via measured/reported intensity/counts as a function of an independent variable. - If the functional form is not empirical or gaussian, users + If the functional form is not empirical or Gaussians, users should enter other for the peak_model and add relevant details in the NXcollection. @@ -80,7 +80,7 @@ In the case of an analytical description (or if peak_model is other) this collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, + For example in the case of Gaussians mu, sigma, cut-off values, and background intensity are relevant parameter. diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index a57b1af0d..9bb6e6079 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - + - Total number of ions collected. + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + Base class for a laser- and/or voltage-pulsing device used in atom probe + microscopy. - + - How is field evaporation physically triggered. + Detail whereby ion extraction is triggered methodologically. @@ -46,14 +48,28 @@ + - Frequency with which the high voltage or laser pulser fires. + Frequency with which the pulser fire(s). - - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + @@ -61,48 +77,72 @@ 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. + (as a function of standing voltage). Otherwise, this field should + not be present. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - + + - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + Pulsed voltage, in laser pulsing mode this field can be omitted. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + Absolute number of pulses starting from the beginning of the experiment. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. - The standing voltage applied to the sample, relative to system ground. + the case of local electrode atom probe (LEAP) instrument. Otherwise, the + standing voltage applied to the sample, relative to system ground. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. + Atom probe microscopes use controlled laser, voltage, or a combination of + pulsing strategies to trigger ion extraction via exciting and eventual field evaporation + field emission of ion at the specimen surface. - + Given name/alias. @@ -118,38 +158,70 @@ Nominal power of the laser source while illuminating the specimen. - Average energy of the laser at peak of each pulse. + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - Details about specific positions along the focused laser beam + 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 in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. + Track time-dependent settings over the course of the measurement + how the laser beam shines on the specimen, i.e. the mean vector + is parallel to the laser propagation direction. - - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. + Track time-dependent settings over the course of the measurement + where the laser beam exits the focusing optics. - - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + @@ -157,10 +229,10 @@ laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. + diff --git a/base_classes/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml index e2220a1be..4bde635a5 100644 --- a/base_classes/NXreflectron.nxdl.xml +++ b/base_classes/NXreflectron.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 + resolved by an instance of :ref:`NXevent_data_apm`. + + + - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + Base class for a 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 - + + + Status of eventual existence and potential usage of this reflectron. + + + + + + + + Given name/alias. - + Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. - + + + The maximum voltage applied to the reflectron, relative to system ground. + + + - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. + Affine transformation(s) which detail where the reflectron is located + relative to e.g. the origin of the specimen space reference coordinate + system. This group can also be used for specifying how the reflectron + is rotated relative to a given axis in the instrument. + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + 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). + + + + + Base class to document an algorithm for recovering charge state and nuclid 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 the nuclids 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 proton numbers for each element of the ranging + definition. The list contains each element as many times as its multiplicity. + As an example a ranging definition H:2 O:1 demands element vector + to be 1, 1, 8. An empty list does not release the constraint. + Instead, a list with all elements in the periodic table should be + used. Keep in mind though with such 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 nuclid of each + (molecular) ion needs to be stable such that the ion qualifies as a candidate. + + + + + Input constraint, minimum natural abundance of each nuclid 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 + nuclids but the charge_state of all the ions is the same. + + + + + + Signed charge, i.e. integer multiple of the elementary charge. + + + + + + + + List of nuclids building each candidate. + Each list is sorted in descending order. + Unused values up to n_ivec_max are nullified. + + + + + + + + + Accumulated mass of the nuclids in each candidate. + Not corrected for quantum effects. + + + + + + + + The product of the natural abundances of the nuclids for each candidate. + + + + + + + + For each candidate the half life of the nuclid with the shortest half life. + + + + + + diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml new file mode 100644 index 000000000..61338a807 --- /dev/null +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of delay-line wires of the detector. + + + + + 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 an application + definition is used to store results of already reconstructed datasets. + + + + + Base class for the configuration and results from a hit finding algorithm. + + + + + + + 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. + + + + + + + + + + + Evaluated ion impact coordinates on the detector. + Use the depends_on field to spec + + + + + + + + The instance of :ref:`NXcoordinate_system` in which the positions are defined. + + + + + + Hit category, AMETEK/Cameca uses e.g. golden, partial, incomplete. + + + + + + + + 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 (which is instead encoded with the + isotope_vector field of each :ref:`NXion` instance). + + + + + + + diff --git a/contributed_definitions/NXapm_msr.nxdl.xml b/contributed_definitions/NXapm_msr.nxdl.xml new file mode 100644 index 000000000..c5ccceff5 --- /dev/null +++ b/contributed_definitions/NXapm_msr.nxdl.xml @@ -0,0 +1,176 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. + + + + + Base class for collecting a session with a real atom probe or field-ion microscope. + + Ideally, we would like to describe the workflow of experiments and simulations of atom probe and + field-evaporation simulation research in more detail and contextualize better descriptions of + experiments and computer simulations for atom probe research. + + The main motivation for this is the ongoing development and tighter becoming connection between atom probe + and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). + To arrive at a design of base classes and an application definition which 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 + wortwhile 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 are can be considered + as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling + i.e. algorithms for defining 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. 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 hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit + time and course of the experiment given that ion extraction is a sequential physical 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>`_ , or `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. + + By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the + whereabouts of each ion evaporated if needed. 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 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 its reconstructions. 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 addition 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 are simplified + because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. + Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path + instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). + + To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become + obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a + real atom probe if considering that the simulation is just stripped of many components. + + + + Metadata of the atom probe or field-ion microscope instrument, henceforth called + microscope or instrument, and the lab in which it stands. + + + + Possibility to include a detailed computational geometry description of the + instrument. + + + + + Given name of the microscope as defined by the hosting lab. This is an alias. + Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + A counter electrode of the LEAP 6000 series atom probes. + + + + + + A local electrode guiding the ion flight path. + Also called counter or extraction electrode. + + + + + + Detector for taking raw time-of-flight and ion/hit impact positions data. + + + + + + + + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml new file mode 100644 index 000000000..b722fbd76 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -0,0 +1,240 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching molecular + ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + 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. + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml new file mode 100644 index 000000000..d31d7d22e --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -0,0 +1,259 @@ + + + + + + + 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-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-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. + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 + as its respective value in the iontypes array. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + The iontype (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 elements of which a (molecular) ion + was built are considered. + + + + + + + + A bitmask which identifies exactly all those ions ranged + irrespective of the assigned type. This information + can be used to numerically recover the ROI selection. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml new file mode 100644 index 000000000..1a08c8b20 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -0,0 +1,140 @@ + + + + + + + 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). + + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + 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. + + + + + + Metadata of the computational process whereby this configuration was generated. + There is a special set of tools called paraprobe-parmsetup which can be used + to conveniently create HDF5 configuration files, i.e. instances. + + + + 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 creation of the configuration 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 creation of the configuration was + completed and the respective process of the tool exited. + + + + + + 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. + 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 to use for this analysis. + + + + + + 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. + + + + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml new file mode 100644 index 000000000..faa3b608d --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + + Base class documenting the results obtained with a tool 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 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). + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + Possibility for leaving a free-text description about this analysis. + + + + + The configuration file that was used to parameterize the algorithms + which the tool executes. + + + + + + + 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 were + completed and the respective process of the tool exited. + + + + + 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 + b that the tool has terminated prematurely or another error occurred. + + + + + + + + + + + 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 + rpresentations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml new file mode 100644 index 000000000..f0c133749 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Application definition for a configuration file of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml new file mode 100644 index 000000000..1534ba86b --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -0,0 +1,197 @@ + + + + + + + + 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. + + + + + 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. + 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 for + information exchange 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, document the provenance of, and thus the + sequence in which certain analysis steps were performed or which specific input and + configuration was used. + + 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 that enable 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. + + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + Mass-to-charge-state-ratio values. + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + Point to the coordinate system in which these 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/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml new file mode 100644 index 000000000..340a5d0b9 --- /dev/null +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + 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>`_ + + + + + + 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>`_). + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml new file mode 100644 index 000000000..e88e3a91f --- /dev/null +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -0,0 +1,102 @@ + + + + + + + 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 + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! + + + + + 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. + + + + + + + + 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 parameterizing this further. + + If no crystallographic calibration was performed, the field + should be filled with the n/a, meaning not applied. + + + + + + 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_sim.nxdl.xml b/contributed_definitions/NXapm_sim.nxdl.xml new file mode 100644 index 000000000..9c4a1d5d6 --- /dev/null +++ b/contributed_definitions/NXapm_sim.nxdl.xml @@ -0,0 +1,40 @@ + + + + + + + Base class for simulating ion extraction from matter via laser and/or voltage pulsing. + + Ideally, we would like to describe the workflow of experiments and simulations of + atom probe and field-evaporation simulation research in more detail and contextualize + better descriptions of experiments and computer simulations. + The strategy to achieve this is detailed in the introducing docstring of + :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the + twin of the :ref:`NXapm_msr` base class. + + + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml new file mode 100644 index 000000000..aa67d8f7e --- /dev/null +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + 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 + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! + + + + + Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. + + The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position + flight path differences, detector biases, and nonlinearities. + + + + + + + Raw time-of-flight data without corrections. + + + + + + + + Calibrated time-of-flight. + + + + + + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..fe1707aa1 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,23 +48,23 @@ - Base class to describe the delocalization of point-like objects on a grid. + Base class of the configuration and results of a delocalization algorithm. - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. + Delocalization is used to distribute point-like objects on a grid to obtain + e.g. smoother count, composition, or concentration values of scalar fields + and compute gradients of these fields. - + - Reference or link to the grid on which the delocalization is applied. + Details about the grid on which the delocalization is applied. - - - - Reference or link to the points which are delocalized on the grid. - - + + - + - The weighting model specifies how mark data are mapped to a weight per point. + The weighting model specifies how mark data are mapped to a weight per point/object. For atom probe microscopy (APM) as an example, different models are used which account differently for the multiplicity of an ion/atom: * default, points all get the same weight 1.; - for APM this is equivalent to ion species + for APM this is equivalent to (molecular) iontype-based delocalization * atomic_decomposition, points get as much weight as they have atoms of a type in element_whitelist, * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. + nuclids of a type in isotope_whitelist. This description shows an example that could be reinterpreted for similar such data processing steps in other fields of science. @@ -124,22 +124,22 @@ i.e. if isotope_decomposition is set isotope_whitelist is required?--> - + Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. - + Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, according to the details of the weighting_model. diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml new file mode 100644 index 000000000..66029763b --- /dev/null +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -0,0 +1,265 @@ + + + + + + + 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. + + 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 splitted 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_identifier 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 + (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_identifier, + 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_identifier 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_identifier the time difference + between when that pulse was issued and start_time. + + In summary, using start_time, end_time, delta_time, pulse_identifier_offset, + and pulse_identifier 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 + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_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 that contextualizes how the detector and pulser of an atom probe + instrument follows a sequence of pulses to trigger field evaporation. + + The pulse_identifier is used to associate thus an information about time + when the quantities documented in this NXpulser_apm base class 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_identifier 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_identifier 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_identifier are then [0, 99999] respectively. + + + + + + + + (Meta)data of the dynamics and changes of the microscope over the course of + pulsing. + + + + + + + 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. + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Average pressure in the analysis chamber during the measurement. + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/contributed_definitions/NXevent_data_apm_set.nxdl.xml new file mode 100644 index 000000000..e4e89e920 --- /dev/null +++ b/contributed_definitions/NXevent_data_apm_set.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + Base class for a set of :ref:`NXevent_data_apm` instances. + + Members of the set are instances of :ref:`NXevent_data_apm`. + These have an associated time interval during which the conditions + of the instrument were considered stable and fit enough for purpose. + + 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 evaporated_identifier but as a + function of the (pulsing) event_identifier. + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,29 +43,26 @@ - Total number of similarity groups aka features, objects, clusters. + Total number of similarity groups aka features/clusters. - Metadata to the results of a similarity grouping analysis. + Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - Similarity grouping analyses can be supervised segmentation or machine learning - clustering algorithms. These are routine methods which partition the member of - a set of objects/geometric primitives into (sub-)groups, features of - different type. A plethora of algorithms have been proposed which can be applied - also on geometric primitives like points, triangles, or (abstract) features aka - objects (including categorical sub-groups). + 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 one similarity grouping - analysis applied to a set in which objects are either categorized as noise - or belonging to a cluster. - As the results of the analysis each similarity group, here called feature - aka object can get a number of numerical and/or categorical labels. + 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 is partitioned into features. + Number of members in the set which gets partitioned into features. @@ -78,26 +75,25 @@ How many categorical labels does each feature have. - - + + - Which identifier is the first to be used to label a cluster. + Which numerical identifier 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 an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. + * 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 - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. - - - - + Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance @@ -112,8 +108,6 @@ Matrix of categorical attribute data for each member in the set. - @@ -121,44 +115,39 @@ e.g. (NXclustering_hdbscan):--> - In addition to the detailed storage which members was grouped to which + In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. - - + + - Total number of members in the set which are categorized as unassigned. + Total number of features categorized as unassigned. - - - - Total number of members in the set which are categorized as noise. + Total number of features categorized as noise. - - - - - + - Total number of clusters (excluding noise and unassigned). + Total number of features. - + + - Array of numerical identifier of each feature (cluster). + Array of numerical identifier of each feature. - + - - + - Array of number of members for each feature. + Array of number of objects for each feature. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 89c04950e..25e5ae820 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + + - Settings of a filter to sample entries based on their value. + Base class of a filter to sample members in a set based on their identifier. - + - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. + Triplet of the minimum, the increment, and the maximum identifier to + include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of identifier. The increment controls which n-th identifier (value) to take. - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. + Take as an example a dataset with 100 identifier (aka entries). Assume that + the identifier start at zero, i.e. identifier_offset is 0). Assume further + that min_incr_max is set to [0, 1, 99]. In this case the filter will + yield all identifier. Setting min_incr_max to [0, 2, 99] will take each + second identifier. Setting min_incr_max to [90, 3, 99] will take each + third identifier beginning from identifier 90 up to 99. From 74258a277dc5f295a123b8cf6417cc1659c75621 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jan 2024 21:52:39 +0100 Subject: [PATCH 111/198] Added changes relevant to use the refactored NXapm parser of pynxtools 0572bfa9df6f513325024185ed1f1c1901d0758c # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml # contributed_definitions/nyaml/NXapm_hit_finding.yaml # contributed_definitions/nyaml/NXapm_ranging.yaml # contributed_definitions/nyaml/NXapm_reconstruction.yaml # contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml # contributed_definitions/nyaml/NXevent_data_apm.yaml # contributed_definitions/nyaml/NXpeak.yaml --- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +-- base_classes/NXpeak.nxdl.xml | 6 ++-- base_classes/NXpulser_apm.nxdl.xml | 4 +-- base_classes/NXreflectron.nxdl.xml | 4 +-- .../NXapm_charge_state_analysis.nxdl.xml | 4 +-- .../NXapm_hit_finding.nxdl.xml | 28 +++++++++++++++++-- contributed_definitions/NXapm_msr.nxdl.xml | 4 +-- .../NXapm_paraprobe_ranger_config.nxdl.xml | 4 +-- .../NXapm_paraprobe_ranger_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_tool_config.nxdl.xml | 4 +-- .../NXapm_paraprobe_tool_results.nxdl.xml | 4 +-- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 4 +-- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 4 +-- .../NXapm_ranging.nxdl.xml | 4 +-- .../NXapm_reconstruction.nxdl.xml | 25 +++++++++++++++-- contributed_definitions/NXapm_sim.nxdl.xml | 4 +-- .../NXapm_volt_and_bowl.nxdl.xml | 4 +-- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +-- .../NXdelocalization.nxdl.xml | 4 +-- .../NXevent_data_apm.nxdl.xml | 28 +++++++++++++++---- .../NXevent_data_apm_set.nxdl.xml | 4 +-- contributed_definitions/NXion.nxdl.xml | 4 +-- contributed_definitions/NXisocontour.nxdl.xml | 4 +-- .../NXmatch_filter.nxdl.xml | 4 +-- .../NXsimilarity_grouping.nxdl.xml | 4 +-- .../NXspatial_filter.nxdl.xml | 4 +-- .../NXsubsampling_filter.nxdl.xml | 4 +-- 27 files changed, 119 insertions(+), 60 deletions(-) diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 8ab218c71..b1f6310dd 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ + + + 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). + + Qualitative statement about which reconstruction protocol was used. @@ -71,6 +82,16 @@ + + + + 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. diff --git a/contributed_definitions/NXapm_sim.nxdl.xml b/contributed_definitions/NXapm_sim.nxdl.xml index 9c4a1d5d6..edc55a2a0 100644 --- a/contributed_definitions/NXapm_sim.nxdl.xml +++ b/contributed_definitions/NXapm_sim.nxdl.xml @@ -2,9 +2,9 @@ - + + + Set point temperature to achieve during the measurement. + + + - Average temperature at the specimen base, i.e. - base_temperature during the measurement. + Average temperature (at the specimen base) during the measurement. - + Average pressure in the analysis chamber during the measurement. diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/contributed_definitions/NXevent_data_apm_set.nxdl.xml index e4e89e920..96670759b 100644 --- a/contributed_definitions/NXevent_data_apm_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm_set.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml index aff5c9b71..7e9d834b8 100644 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -70,6 +70,7 @@ + Description of the type of the detector. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_apm.nxdl.xml rename to base_classes/NXevent_data_apm.nxdl.xml diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/base_classes/NXevent_data_apm_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_apm_set.nxdl.xml rename to base_classes/NXevent_data_apm_set.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml deleted file mode 100644 index 956cd8220..000000000 --- a/base_classes/NXpeak.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Base class for peaks, their functional form, and measured support. - - - - Human-readable label which specifies which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or Gaussians, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 59f5cffc0..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index d0c1d1809..000000000 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e445ff1e7..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 93b35cfef..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index abc88b051..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index d70836aee..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index d1fece068..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 97f1ebd1a..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 972ed6080..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index e9bd12b89..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index d42af5a47..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 50eb894eb4163a88a1cce0ebbb425572201ea07f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 114/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2034 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 12 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 20 +- .../NXcg_half_edge_data_structure.nxdl.xml | 26 +- base_classes/NXcg_marching_cubes.nxdl.xml | 37 +- base_classes/NXcg_polyline_set.nxdl.xml | 12 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 10 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXevent_data_em_set.nxdl.xml | 32 - base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 165 ++ .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- ..._pf_set.nxdl.xml => NXcs_gpu_obj.nxdl.xml} | 26 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 228 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 10 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 379 --- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_odf_set.nxdl.xml | 33 - contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 448 ---- .../NXms_score_results.nxdl.xml | 4 +- .../{NXms_ipf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 93 files changed, 5240 insertions(+), 9982 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXevent_data_em_set.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (67%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXcs_gpu_obj.nxdl.xml} (67%) rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_ipf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index ad33f94aa..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2034 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..260f16e1b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -2,9 +2,9 @@ - + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Base class to detail the marching cubes (MC) algorithm. + Computational geometry description of the marching cubes algorithm. - Documenting which specific version of MC was used helps with understanding - how robust the results are with respect to the topology of the triangulation. + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. - Metadata of the grid on which the here specified MC is operating. + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. - + Reference to the specific implementation of marching cubes used. - See for example the following papers for details about specific - MC implementations: + 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>`_ - - - - - Free text field in case a proper identifier is not available. + + 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. diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..898a56acd 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -2,9 +2,9 @@ even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 4ffc77ba8..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 9d674f6b2..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index e5f40c95a..000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index e3c52b3ef..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 000000000..38a448a0e --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 67% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index bc6d4c291..6ce5370a3 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a (central) processing unit (C)PU of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 67% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index 14a4061d6..3c5b6c26a 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Computer science description of a graphic processing unit (GPU) of a computer. - + + + Given name of the GPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index b00b7ea92..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 193600031..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 9bb45544f..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 721aeca84..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 90c9ae1c1..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml deleted file mode 100644 index c21aa3698..000000000 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_odf` instances. - - A collection of orientation distribution function approximations. - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 7425c8a82..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index 390f03969..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,448 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From d7d24d6e40325ca82bbcc403e53eab3d8af0d472 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 115/198] Make nxdl # Conflicts: # base_classes/NXapm_sim.nxdl.xml # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXapm_sim.nxdl.xml | 40 - base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 58 files changed, 8767 insertions(+), 189 deletions(-) delete mode 100644 base_classes/NXapm_sim.nxdl.xml delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXapm_sim.nxdl.xml b/base_classes/NXapm_sim.nxdl.xml deleted file mode 100644 index edc55a2a0..000000000 --- a/base_classes/NXapm_sim.nxdl.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - - Base class for simulating ion extraction from matter via laser and/or voltage pulsing. - - Ideally, we would like to describe the workflow of experiments and simulations of - atom probe and field-evaporation simulation research in more detail and contextualize - better descriptions of experiments and computer simulations. - The strategy to achieve this is detailed in the introducing docstring of - :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the - twin of the :ref:`NXapm_msr` base class. - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml new file mode 100644 index 000000000..0f753001e --- /dev/null +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 0884c7603ae83b69066828e01c2f7e02f7a67fd5 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 116/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 83 files changed, 207 insertions(+), 164 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + From 1e25411e9ec9bcf1ee9dd2a129d079d230d8813c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jan 2024 21:52:39 +0100 Subject: [PATCH 118/198] Added changes relevant to use the refactored NXapm parser of pynxtools 0572bfa9df6f513325024185ed1f1c1901d0758c # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpeak.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml # contributed_definitions/nyaml/NXapm_hit_finding.yaml # contributed_definitions/nyaml/NXapm_ranging.yaml # contributed_definitions/nyaml/NXapm_reconstruction.yaml # contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml # contributed_definitions/nyaml/NXevent_data_apm.yaml # contributed_definitions/nyaml/NXpeak.yaml --- contributed_definitions/NXapm.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 87 +++++++++++++++++++++++++ 2 files changed, 89 insertions(+), 2 deletions(-) create mode 100644 contributed_definitions/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + From c2f3703ae4cd9a6802fc207b44c7d54b93f70d0d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:27:41 +0100 Subject: [PATCH 119/198] Recompiled NXDLs from YAML using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml --- .../NXapm_charge_state_analysis.nxdl.xml | 14 +- base_classes/NXapm_hit_finding.nxdl.xml | 12 +- base_classes/NXapm_ranging.nxdl.xml | 2 +- base_classes/NXapm_reconstruction.nxdl.xml | 6 +- base_classes/NXapm_volt_and_bowl.nxdl.xml | 4 +- base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXevent_data_apm.nxdl.xml | 14 +- base_classes/NXpulser_apm.nxdl.xml | 35 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 259 ------------ .../NXapm_paraprobe_tool_results.nxdl.xml | 136 ------ ...Xapm_paraprobe_transcoder_results.nxdl.xml | 197 --------- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 6 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 54 +-- contributed_definitions/NXem_base.nxdl.xml | 389 ------------------ .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 144 ------- contributed_definitions/NXem_eels.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 247 ----------- .../NXimage_r_set.nxdl.xml | 100 ----- contributed_definitions/NXion.nxdl.xml | 4 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 8 +- .../NXsimilarity_grouping.nxdl.xml | 8 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 51 files changed, 171 insertions(+), 1658 deletions(-) delete mode 100644 contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_eds.nxdl.xml delete mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml diff --git a/base_classes/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml index 3b6191151..7acd17984 100644 --- a/base_classes/NXapm_charge_state_analysis.nxdl.xml +++ b/base_classes/NXapm_charge_state_analysis.nxdl.xml @@ -70,7 +70,7 @@ input/config--> used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 7ea1adbfe..f320adda2 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml deleted file mode 100644 index 4d6ddfaaf..000000000 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ /dev/null @@ -1,259 +0,0 @@ - - - - - - - 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-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-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. - - - - - Version specifier of this application definition. - - - - - NeXus NXDL schema with which this file was written. - - - - - - - - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 - as its respective value in the iontypes array. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - The iontype (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 elements of which a (molecular) ion - was built are considered. - - - - - - - - A bitmask which identifies exactly all those ions ranged - irrespective of the assigned type. This information - can be used to numerically recover the ROI selection. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml deleted file mode 100644 index 5c2f632be..000000000 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - - Base class documenting the results obtained with a tool 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 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). - - - - - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - - - - - Possibility for leaving a free-text description about this analysis. - - - - - The configuration file that was used to parameterize the algorithms - which the tool executes. - - - - - - - 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 were - completed and the respective process of the tool exited. - - - - - 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 - b that the tool has terminated prematurely or another error occurred. - - - - - - - - - - - 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 - rpresentations 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 deleted file mode 100644 index d227bc52b..000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - 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. - 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 for - information exchange 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, document the provenance of, and thus the - sequence in which certain analysis steps were performed or which specific input and - configuration was used. - - 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 that enable 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. - - - - - - Version specifier of this application definition. - - - - - NeXus NXDL schema with which this file was written. - - - - - - - - - - - Mass-to-charge-state-ratio values. - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - Point to the coordinate system in which these 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/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index c00dfc240..e5e5e8860 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 96ac16827..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,23 +48,23 @@ - Base class of the configuration and results of a delocalization algorithm. + Base class to describe the delocalization of point-like objects on a grid. - Delocalization is used to distribute point-like objects on a grid to obtain - e.g. smoother count, composition, or concentration values of scalar fields - and compute gradients of these fields. + Such a procedure is for instance used in image processing and e.g. atom probe + microscopy (APM) to discretize a point cloud onto a grid to enable e.g. + computing of point density, composition, or concentration values, obtain + scalar fields, and compute gradients of these fields. - + + + Reference or link to the grid on which the delocalization is applied. + + + - Details about the grid on which the delocalization is applied. + Reference or link to the points which are delocalized on the grid. - - + - + - The weighting model specifies how mark data are mapped to a weight per point/object. + The weighting model specifies how mark data are mapped to a weight per point. For atom probe microscopy (APM) as an example, different models are used which account differently for the multiplicity of an ion/atom: * default, points all get the same weight 1.; - for APM this is equivalent to (molecular) iontype-based delocalization + for APM this is equivalent to ion species * atomic_decomposition, points get as much weight as they have atoms of a type in element_whitelist, * isotope_decomposition, points get as much weight as they have - nuclids of a type in isotope_whitelist. + isotopes of a type in isotope_whitelist. This description shows an example that could be reinterpreted for similar such data processing steps in other fields of science. @@ -124,22 +124,22 @@ i.e. if isotope_decomposition is set isotope_whitelist is required?--> - + Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. - + Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, according to the details of the weighting_model. diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml deleted file mode 100644 index 2117081ba..000000000 --- a/contributed_definitions/NXem_base.nxdl.xml +++ /dev/null @@ -1,389 +0,0 @@ - - - - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 6a51d87550e0eabac1bed213643e4e44fe903f1e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 120/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index f320adda2..7ea1adbfe 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 95f0e8c41..a39efa0eb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -63,7 +63,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -72,7 +72,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 19dcef583317b9e6f4e734ebe71e091a78602776 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 122/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - + 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. + The cardinality of the set, i.e. the number of cylinders or cones. - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders in Euclidean space. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. - + + + + + + + - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - + + + + Integer used to distinguish members for explicit indexing. + + - - - + - Radius of the cylinder if all have the same radius. + The geometric center of each member. + + + + - + - Radii of the cylinder. + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. - + + + + + + + + - + - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + - + - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + - Lateral surface area + Interior volume of each cylinder - + - + - Area of the upper cap of each cylinder. + Lateral surface area - + - + - Area of the lower cap of each cylinder. + Area of the upper and the lower cap of each cylinder respectively. - + + - + - Sum of upper and lower cap areas and lateral surface area - of each cylinder. + Cap and lateral surface area for each cylinder. - + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system.nxdl.xml rename to base_classes/NXcoordinate_system.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcrystal_structure.nxdl.xml rename to base_classes/NXcrystal_structure.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_correlation.nxdl.xml rename to base_classes/NXem_correlation.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eels.nxdl.xml rename to base_classes/NXem_eels.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index e5e5e8860..000000000 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From d8f8005348c545ba352401326504266a8bd07882 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 124/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 128 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 22 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 94 files changed, 7246 insertions(+), 8048 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + 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 cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius 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 lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml similarity index 56% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXcs_mm_obj.nxdl.xml index 9f38b2d7b..e2b247079 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index edf318e2a..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - + - Given name/alias. + Details about processing steps. - - - - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. - - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 0ff46b165d97099c9f4ddff63e9fa350395f81d4 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 125/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + .../NXpump.nxdl.xml | 41 +- contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8501 insertions(+), 228 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXpump.nxdl.xml (53%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 53% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index aaad75e98..9f38b2d7b 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Device to reduce an atmosphere to a controlled remaining pressure level. - + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Principle type of the pump. - - - 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/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 6df46547105f012e442accde30b4e43a259bb588 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 126/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 40 ++++++ .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 403 insertions(+), 184 deletions(-) create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0b1f581a8..a68436e9b 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 7ea1adbfe..f320adda2 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..dd5f5246d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 5e3e1480dbdfbd27376ee82f651bb24238f4a9f5 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 129/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index f320adda2..7ea1adbfe 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 07052bdddfa3fe494a90bc63e9718c94ee7ae7c7 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 131/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,17 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - @@ -187,7 +176,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..f57d0c53f 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,6 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - - - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. - - The total number of vertices that have different positions. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..c3636c6b3 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 586929596..68b87e47e 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -36,10 +36,9 @@ NXcg_primitive_set(NXobject): # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. dimensionality(NX_POSINT): doc: | The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 9a5a97fcd..e9d15f5b0 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -6,6 +6,7 @@ doc: | # 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_p: Number of scan points n_y: | @@ -13,7 +14,7 @@ symbols: n_x: | Number of pixel along the x direction, the fast direction n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | From c296d586fdde0baa1b989ea9cd599b55f905994c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 133/198] move new definitions to application and base_classes # Conflicts: # applications/NXellipsometry.nxdl.xml # applications/NXmpes_arpes.nxdl.xml # applications/NXoptical_spectroscopy.nxdl.xml # applications/NXraman.nxdl.xml # applications/NXxps.nxdl.xml # applications/xps/xps_cs.png # base_classes/NXactivity.nxdl.xml # base_classes/NXactuator.nxdl.xml # base_classes/NXapm_sim.nxdl.xml # base_classes/NXbeam_device.nxdl.xml # base_classes/NXbeam_transfer_matrix_table.nxdl.xml # base_classes/NXchemical_process.nxdl.xml # base_classes/NXcircuit.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXcomponent.nxdl.xml # base_classes/NXdata_mpes.nxdl.xml # base_classes/NXdata_mpes_detector.nxdl.xml # base_classes/NXelectron_level.nxdl.xml # base_classes/NXem_eds.nxdl.xml # base_classes/NXfit.nxdl.xml # base_classes/NXfit_background.nxdl.xml # base_classes/NXfit_function.nxdl.xml # base_classes/NXfit_parameter.nxdl.xml # base_classes/NXhistory.nxdl.xml # base_classes/NXidentifier.nxdl.xml # base_classes/NXmanipulator.nxdl.xml # base_classes/NXopt_window.nxdl.xml # base_classes/NXphysical_process.nxdl.xml # base_classes/NXprocess_mpes.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXresolution.nxdl.xml # base_classes/NXrotation_set.nxdl.xml # base_classes/NXsample_component_set.nxdl.xml # base_classes/NXserialized.nxdl.xml # base_classes/NXsingle_crystal.nxdl.xml # base_classes/NXspindispersion.nxdl.xml # base_classes/NXsubstance.nxdl.xml # base_classes/NXunit_cell.nxdl.xml # contributed_definitions/NXactivity.nxdl.xml # contributed_definitions/NXadc.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXcs_cpu_obj.nxdl.xml # contributed_definitions/NXcs_cpu_sys.nxdl.xml # contributed_definitions/NXcs_mm_obj.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXfit_function.nxdl.xml # contributed_definitions/NXfit_parameter.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_snapshot.nxdl.xml # contributed_definitions/NXprogram.nxdl.xml # contributed_definitions/NXregistration.nxdl.xml # contributed_definitions/NXunit_cell.nxdl.xml # contributed_definitions/nyaml/NXcg_primitive_set.yaml # contributed_definitions/nyaml/NXcoordinate_system.yaml # contributed_definitions/nyaml/NXcrystal_structure.yaml # contributed_definitions/nyaml/NXem_correlation.yaml # contributed_definitions/nyaml/NXem_eds.yaml # contributed_definitions/nyaml/NXem_eels.yaml # contributed_definitions/nyaml/NXem_img.yaml # contributed_definitions/nyaml/NXem_method.yaml # contributed_definitions/nyaml/NXem_msr.yaml # contributed_definitions/nyaml/NXem_sim.yaml # contributed_definitions/nyaml/NXroi.yaml --- .../NXapm.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXaberration.nxdl.xml | 0 .../NXchamber.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXfabrication.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXaperture_em.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 111 ------ .../NXcg_ellipsoid_set.nxdl.xml | 135 ------- .../NXcg_face_list_data_structure.nxdl.xml | 243 ------------ .../NXcg_hexahedron_set.nxdl.xml | 239 ----------- .../NXcg_parallelogram_set.nxdl.xml | 183 --------- .../NXcg_point_set.nxdl.xml | 98 ----- .../NXcg_polygon_set.nxdl.xml | 227 ----------- .../NXcg_polyhedron_set.nxdl.xml | 194 --------- .../NXcg_primitive_set.nxdl.xml | 212 ---------- .../NXcg_sphere_set.nxdl.xml | 121 ------ .../NXcg_tetrahedron_set.nxdl.xml | 175 --------- .../NXcg_triangle_set.nxdl.xml | 132 ------- .../NXcoordinate_system.nxdl.xml | 143 ------- .../NXcrystal_structure.nxdl.xml | 280 ------------- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 --- .../NXelectronanalyser.nxdl.xml | 157 -------- .../NXem_correlation.nxdl.xml | 245 ------------ contributed_definitions/NXem_eels.nxdl.xml | 79 ---- contributed_definitions/NXem_msr.nxdl.xml | 97 ----- contributed_definitions/NXem_sim.nxdl.xml | 60 --- .../NXenergydispersion.nxdl.xml | 90 ----- .../NXinteraction_vol_em.nxdl.xml | 37 -- contributed_definitions/NXmpes.nxdl.xml | 371 ------------------ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 -- ...Xcs_mm_obj.nxdl.xml => NXprogram.nxdl.xml} | 41 +- ...u_obj.nxdl.xml => NXregistration.nxdl.xml} | 42 +- .../nyaml/NXcg_primitive_set.yaml | 135 ------- .../nyaml/NXcoordinate_system.yaml | 86 ---- .../nyaml/NXcrystal_structure.yaml | 178 --------- .../nyaml/NXem_correlation.yaml | 191 --------- contributed_definitions/nyaml/NXem_eds.yaml | 81 ---- contributed_definitions/nyaml/NXem_eels.yaml | 39 -- contributed_definitions/nyaml/NXem_img.yaml | 25 -- .../nyaml/NXem_method.yaml | 21 - contributed_definitions/nyaml/NXem_msr.yaml | 63 --- contributed_definitions/nyaml/NXem_sim.yaml | 34 -- contributed_definitions/nyaml/NXroi.yaml | 9 - 68 files changed, 52 insertions(+), 4607 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfabrication.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml delete mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml delete mode 100644 contributed_definitions/NXem_correlation.nxdl.xml delete mode 100644 contributed_definitions/NXem_eels.nxdl.xml delete mode 100644 contributed_definitions/NXem_msr.nxdl.xml delete mode 100644 contributed_definitions/NXem_sim.nxdl.xml delete mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml rename contributed_definitions/{NXcs_mm_obj.nxdl.xml => NXprogram.nxdl.xml} (57%) rename contributed_definitions/{NXcs_cpu_obj.nxdl.xml => NXregistration.nxdl.xml} (53%) delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.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_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index c3636c6b3..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 68b87e47e..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,135 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index e9d15f5b0..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,81 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 19b95ddfc113a935301fda410e19e2008fe0941f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 134/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 21 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 13 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 23 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 93 files changed, 5067 insertions(+), 9919 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (68%) rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,6 +54,17 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + Dimensionality of the primitives described. + + @@ -176,7 +187,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 4cc765fd8..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 68% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index edf318e2a..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 10448a17b7c396e6b363be297a5052a108da3e95 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 135/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 46 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 40 + .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXfabrication.nxdl.xml | 48 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 61 files changed, 8851 insertions(+), 156 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (51%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - + The symbols used in the schema to specify e.g. dimensions of arrays. - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. + Computer science description of a system of coprocessor or graphics processors. - - - In the case that all spheres have the same radius. - - - + - In the case that spheres have different radius use this - instead of the radius field. + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. - - - - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index 5aebe0d78..58454a5e1 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 51% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index 0034919dd..1f940f079 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Details about processing steps. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - - - + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From f249898a179de89b426dbab4095440d2bbbf4202 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 136/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 85 files changed, 211 insertions(+), 168 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index e05baf1ea..1f41de1e8 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..dd5f5246d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From ee91f0038dc9131496154871013f054aab65968b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 139/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 1f41de1e8..e05baf1ea 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 010820b619a461030a7193abffc0061f2a446469 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 141/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - From 49ab8a678697bc4e40e252e08eec7337d10a1c50 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 143/198] move new definitions to application and base_classes # Conflicts: # applications/NXellipsometry.nxdl.xml # applications/NXmpes_arpes.nxdl.xml # applications/NXoptical_spectroscopy.nxdl.xml # applications/NXraman.nxdl.xml # applications/NXxps.nxdl.xml # applications/xps/xps_cs.png # base_classes/NXactivity.nxdl.xml # base_classes/NXactuator.nxdl.xml # base_classes/NXapm_sim.nxdl.xml # base_classes/NXbeam_device.nxdl.xml # base_classes/NXbeam_transfer_matrix_table.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXchemical_process.nxdl.xml # base_classes/NXcircuit.nxdl.xml # base_classes/NXcomponent.nxdl.xml # base_classes/NXdata_mpes.nxdl.xml # base_classes/NXdata_mpes_detector.nxdl.xml # base_classes/NXelectron_level.nxdl.xml # base_classes/NXem_eds.nxdl.xml # base_classes/NXfit.nxdl.xml # base_classes/NXfit_background.nxdl.xml # base_classes/NXfit_function.nxdl.xml # base_classes/NXfit_parameter.nxdl.xml # base_classes/NXhistory.nxdl.xml # base_classes/NXidentifier.nxdl.xml # base_classes/NXmanipulator.nxdl.xml # base_classes/NXopt_window.nxdl.xml # base_classes/NXphysical_process.nxdl.xml # base_classes/NXprocess_mpes.nxdl.xml # base_classes/NXresolution.nxdl.xml # base_classes/NXrotation_set.nxdl.xml # base_classes/NXsample_component_set.nxdl.xml # base_classes/NXserialized.nxdl.xml # base_classes/NXsingle_crystal.nxdl.xml # base_classes/NXspindispersion.nxdl.xml # base_classes/NXsubstance.nxdl.xml # base_classes/NXunit_cell.nxdl.xml # contributed_definitions/NXactivity.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXcomponent.nxdl.xml # contributed_definitions/NXcs_cpu_obj.nxdl.xml # contributed_definitions/NXcs_cpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_obj.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXfit_function.nxdl.xml # contributed_definitions/NXfit_parameter.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXunit_cell.nxdl.xml # contributed_definitions/nyaml/NXcg_primitive_set.yaml # contributed_definitions/nyaml/NXcoordinate_system.yaml # contributed_definitions/nyaml/NXcrystal_structure.yaml # contributed_definitions/nyaml/NXem_correlation.yaml # contributed_definitions/nyaml/NXem_eds.yaml # contributed_definitions/nyaml/NXem_eels.yaml # contributed_definitions/nyaml/NXem_img.yaml # contributed_definitions/nyaml/NXem_method.yaml # contributed_definitions/nyaml/NXem_msr.yaml # contributed_definitions/nyaml/NXem_sim.yaml # contributed_definitions/nyaml/NXroi.yaml --- .../NXapm.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXaberration.nxdl.xml | 0 base_classes/NXcg_sphere_set.nxdl.xml | 104 ++++- .../NXchamber.nxdl.xml | 0 .../NXcollectioncolumn.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXfabrication.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXprogram.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXregistration.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXaperture_em.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 111 ------ .../NXcg_ellipsoid_set.nxdl.xml | 135 ------- .../NXcg_face_list_data_structure.nxdl.xml | 243 ------------ .../NXcg_hexahedron_set.nxdl.xml | 239 ----------- .../NXcg_parallelogram_set.nxdl.xml | 183 --------- .../NXcg_point_set.nxdl.xml | 98 ----- .../NXcg_polygon_set.nxdl.xml | 227 ----------- .../NXcg_polyhedron_set.nxdl.xml | 194 --------- .../NXcg_primitive_set.nxdl.xml | 212 ---------- .../NXcg_sphere_set.nxdl.xml | 121 ------ .../NXcg_tetrahedron_set.nxdl.xml | 175 --------- .../NXcg_triangle_set.nxdl.xml | 132 ------- .../NXcoordinate_system.nxdl.xml | 143 ------- .../NXcrystal_structure.nxdl.xml | 280 ------------- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 -- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 --- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 --- .../NXelectronanalyser.nxdl.xml | 157 -------- .../NXem_correlation.nxdl.xml | 245 ------------ contributed_definitions/NXem_eels.nxdl.xml | 79 ---- contributed_definitions/NXem_msr.nxdl.xml | 97 ----- contributed_definitions/NXem_sim.nxdl.xml | 60 --- .../NXenergydispersion.nxdl.xml | 90 ----- .../NXinteraction_vol_em.nxdl.xml | 37 -- contributed_definitions/NXmpes.nxdl.xml | 371 ------------------ .../nyaml/NXcg_primitive_set.yaml | 136 ------- .../nyaml/NXcoordinate_system.yaml | 86 ---- .../nyaml/NXcrystal_structure.yaml | 178 --------- .../nyaml/NXem_correlation.yaml | 191 --------- contributed_definitions/nyaml/NXem_eds.yaml | 80 ---- contributed_definitions/nyaml/NXem_eels.yaml | 39 -- contributed_definitions/nyaml/NXem_img.yaml | 25 -- .../nyaml/NXem_method.yaml | 21 - contributed_definitions/nyaml/NXem_msr.yaml | 63 --- contributed_definitions/nyaml/NXem_sim.yaml | 34 -- contributed_definitions/nyaml/NXroi.yaml | 9 - 73 files changed, 95 insertions(+), 4650 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcollectioncolumn.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfabrication.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXprogram.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXregistration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml delete mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml delete mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml delete mode 100644 contributed_definitions/NXem_correlation.nxdl.xml delete mode 100644 contributed_definitions/NXem_eels.nxdl.xml delete mode 100644 contributed_definitions/NXem_msr.nxdl.xml delete mode 100644 contributed_definitions/NXem_sim.nxdl.xml delete mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.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_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index e7fedabd4..e50192cf8 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + - Computer science description of a system of coprocessor or graphics processors. + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. - + + + - Granularizing at the socket level. + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From bb8787cd4ff0176d07f85121ff7775d2e5db9dd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 144/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 8 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_sphere_set.nxdl.xml | 74 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ .../NXms_odf_set.nxdl.xml | 28 +- contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 93 files changed, 7056 insertions(+), 8015 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXms_odf_set.nxdl.xml (53%) create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/base_classes/NXfabrication.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml similarity index 57% rename from base_classes/NXfabrication.nxdl.xml rename to contributed_definitions/NXcs_mm_obj.nxdl.xml index 5ec33932b..e2b247079 100644 --- a/base_classes/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml similarity index 53% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXms_odf_set.nxdl.xml index 9f38b2d7b..d41a609a8 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. - - - - Principle type of the pump. - - - - - - - - - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 09ff8674fd611465ce87b8255213f0a52212f3f8 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 145/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8486 insertions(+), 204 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 126697be5a62e33a43a57b828aa55d360bbd02b6 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 146/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 40 ++++++ .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 ++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 96 files changed, 397 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0b1f581a8..a68436e9b 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 8b1283474..58d4d5796 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml index aff5c9b71..7e9d834b8 100644 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -70,6 +70,7 @@ + Description of the type of the detector. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 59f5cffc0..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index d0c1d1809..000000000 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e445ff1e7..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 93b35cfef..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index d70836aee..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index d1fece068..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 97f1ebd1a..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 972ed6080..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index e9bd12b89..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index d42af5a47..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 65bf96cc618013404cef7dc186849da9cc3c977f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 150/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2034 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 12 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 20 +- .../NXcg_half_edge_data_structure.nxdl.xml | 26 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 12 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 10 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 165 ++ .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 23 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 228 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 10 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 379 --- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 448 ---- .../NXms_score_results.nxdl.xml | 4 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 92 files changed, 5235 insertions(+), 9918 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (68%) rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index ad33f94aa..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2034 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..260f16e1b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -2,9 +2,9 @@ even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 4ffc77ba8..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 9d674f6b2..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index e3c52b3ef..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 000000000..38a448a0e --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 68% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index edf318e2a..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index b00b7ea92..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 193600031..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 9bb45544f..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 721aeca84..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 90c9ae1c1..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 7425c8a82..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index 390f03969..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,448 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 2f5786a09471e5d7e2fce0873eae39977e483029 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 151/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 38 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXfabrication.nxdl.xml | 48 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 59 files changed, 8807 insertions(+), 150 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (57%) create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (51%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - 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/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 51% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index 0034919dd..1f940f079 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Details about a component as defined by its manufacturer. - + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + - Details about processing steps. + Free-text list with eventually multiple terms of + functionalities which the component offers. - - - - - + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From a3fef520baacf3411e4ef9050ead9ac48a98ec1d Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 152/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 84 files changed, 209 insertions(+), 166 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + From 385deb6936410770db9747b5494cb2da5d31be48 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:27:41 +0100 Subject: [PATCH 154/198] Recompiled NXDLs from YAML using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml --- .../NXapm_charge_state_analysis.nxdl.xml | 14 +- base_classes/NXapm_hit_finding.nxdl.xml | 12 +- base_classes/NXapm_ranging.nxdl.xml | 2 +- base_classes/NXapm_reconstruction.nxdl.xml | 6 +- base_classes/NXapm_volt_and_bowl.nxdl.xml | 4 +- base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXevent_data_apm.nxdl.xml | 14 +- base_classes/NXpulser_apm.nxdl.xml | 35 +- .../NXcg_cylinder_set.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 6 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ------------------ .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 144 ------- contributed_definitions/NXem_eels.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 247 ----------- .../NXimage_r_set.nxdl.xml | 100 ----- contributed_definitions/NXion.nxdl.xml | 4 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpeak.nxdl.xml | 8 +- .../NXsimilarity_grouping.nxdl.xml | 8 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 48 files changed, 146 insertions(+), 1041 deletions(-) delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_eds.nxdl.xml delete mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml diff --git a/base_classes/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml index 3b6191151..7acd17984 100644 --- a/base_classes/NXapm_charge_state_analysis.nxdl.xml +++ b/base_classes/NXapm_charge_state_analysis.nxdl.xml @@ -70,7 +70,7 @@ input/config--> used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index e05baf1ea..1f41de1e8 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index c00dfc240..e5e5e8860 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From ba543e9a15e07253e29fff99f66e99d7393ef245 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 155/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 1f41de1e8..e05baf1ea 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 95f0e8c41..a39efa0eb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -63,7 +63,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -72,7 +72,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 609174971b260f32f0d02fa97a9628f2a2445b0a Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 157/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_cylinder_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,17 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - @@ -187,7 +176,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..f57d0c53f 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,6 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - - - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. - - The total number of vertices that have different positions. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..c3636c6b3 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 586929596..68b87e47e 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -36,10 +36,9 @@ NXcg_primitive_set(NXobject): # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. dimensionality(NX_POSINT): doc: | The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 9a5a97fcd..e9d15f5b0 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -6,6 +6,7 @@ doc: | # 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_p: Number of scan points n_y: | @@ -13,7 +14,7 @@ symbols: n_x: | Number of pixel along the x direction, the fast direction n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | From 595a34019c14c053d2b55a47c5c68aa13c6910ed Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 159/198] move new definitions to application and base_classes # Conflicts: # applications/NXellipsometry.nxdl.xml # applications/NXmpes_arpes.nxdl.xml # applications/NXoptical_spectroscopy.nxdl.xml # applications/NXraman.nxdl.xml # applications/NXxps.nxdl.xml # applications/xps/xps_cs.png # base_classes/NXactivity.nxdl.xml # base_classes/NXactuator.nxdl.xml # base_classes/NXapm_sim.nxdl.xml # base_classes/NXbeam_device.nxdl.xml # base_classes/NXbeam_transfer_matrix_table.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXchemical_process.nxdl.xml # base_classes/NXcircuit.nxdl.xml # base_classes/NXcomponent.nxdl.xml # base_classes/NXdata_mpes.nxdl.xml # base_classes/NXdata_mpes_detector.nxdl.xml # base_classes/NXelectron_level.nxdl.xml # base_classes/NXem_eds.nxdl.xml # base_classes/NXfit.nxdl.xml # base_classes/NXfit_background.nxdl.xml # base_classes/NXfit_function.nxdl.xml # base_classes/NXfit_parameter.nxdl.xml # base_classes/NXhistory.nxdl.xml # base_classes/NXidentifier.nxdl.xml # base_classes/NXmanipulator.nxdl.xml # base_classes/NXopt_window.nxdl.xml # base_classes/NXphysical_process.nxdl.xml # base_classes/NXprocess_mpes.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXresolution.nxdl.xml # base_classes/NXrotation_set.nxdl.xml # base_classes/NXsample_component_set.nxdl.xml # base_classes/NXserialized.nxdl.xml # base_classes/NXsingle_crystal.nxdl.xml # base_classes/NXspindispersion.nxdl.xml # base_classes/NXsubstance.nxdl.xml # base_classes/NXunit_cell.nxdl.xml # contributed_definitions/NXactivity.nxdl.xml # contributed_definitions/NXadc.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_sim.nxdl.xml # contributed_definitions/NXcs_cpu_obj.nxdl.xml # contributed_definitions/NXcs_cpu_sys.nxdl.xml # contributed_definitions/NXcs_mm_obj.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXfit_function.nxdl.xml # contributed_definitions/NXfit_parameter.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXms_ipf_set.nxdl.xml # contributed_definitions/NXms_snapshot.nxdl.xml # contributed_definitions/NXprogram.nxdl.xml # contributed_definitions/NXregistration.nxdl.xml # contributed_definitions/NXunit_cell.nxdl.xml # contributed_definitions/nyaml/NXcg_primitive_set.yaml # contributed_definitions/nyaml/NXcoordinate_system.yaml # contributed_definitions/nyaml/NXcrystal_structure.yaml # contributed_definitions/nyaml/NXem_correlation.yaml # contributed_definitions/nyaml/NXem_eds.yaml # contributed_definitions/nyaml/NXem_eels.yaml # contributed_definitions/nyaml/NXem_img.yaml # contributed_definitions/nyaml/NXem_method.yaml # contributed_definitions/nyaml/NXem_msr.yaml # contributed_definitions/nyaml/NXem_sim.yaml # contributed_definitions/nyaml/NXroi.yaml --- .../NXapm.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXaberration.nxdl.xml | 0 base_classes/NXcg_cylinder_set.nxdl.xml | 144 ++++--- base_classes/NXcg_sphere_set.nxdl.xml | 78 +++- .../NXchamber.nxdl.xml | 0 .../NXcollectioncolumn.nxdl.xml | 0 .../NXcoordinate_system.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 .../NXcrystal_structure.nxdl.xml | 0 .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXem_correlation.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_eels.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXfabrication.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXaperture_em.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 111 ------ .../NXcg_cylinder_set.nxdl.xml | 165 -------- .../NXcg_ellipsoid_set.nxdl.xml | 135 ------- .../NXcg_face_list_data_structure.nxdl.xml | 243 ------------ .../NXcg_hexahedron_set.nxdl.xml | 239 ----------- .../NXcg_parallelogram_set.nxdl.xml | 183 --------- .../NXcg_point_set.nxdl.xml | 98 ----- .../NXcg_polygon_set.nxdl.xml | 227 ----------- .../NXcg_polyhedron_set.nxdl.xml | 194 --------- .../NXcg_primitive_set.nxdl.xml | 212 ---------- .../NXcg_sphere_set.nxdl.xml | 121 ------ .../NXcg_tetrahedron_set.nxdl.xml | 175 --------- .../NXcg_triangle_set.nxdl.xml | 132 ------- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 --- .../NXelectronanalyser.nxdl.xml | 157 -------- contributed_definitions/NXem_msr.nxdl.xml | 97 ----- contributed_definitions/NXem_sim.nxdl.xml | 60 --- .../NXenergydispersion.nxdl.xml | 90 ----- .../NXinteraction_vol_em.nxdl.xml | 37 -- contributed_definitions/NXmpes.nxdl.xml | 371 ------------------ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 -- ...Xcs_mm_obj.nxdl.xml => NXprogram.nxdl.xml} | 41 +- ...u_obj.nxdl.xml => NXregistration.nxdl.xml} | 42 +- .../nyaml/NXcg_primitive_set.yaml | 135 ------- .../nyaml/NXcoordinate_system.yaml | 86 ---- .../nyaml/NXcrystal_structure.yaml | 178 --------- .../nyaml/NXem_correlation.yaml | 191 --------- contributed_definitions/nyaml/NXem_eds.yaml | 81 ---- contributed_definitions/nyaml/NXem_eels.yaml | 39 -- contributed_definitions/nyaml/NXem_img.yaml | 25 -- .../nyaml/NXem_method.yaml | 21 - contributed_definitions/nyaml/NXem_msr.yaml | 63 --- contributed_definitions/nyaml/NXem_sim.yaml | 34 -- contributed_definitions/nyaml/NXroi.yaml | 9 - 72 files changed, 203 insertions(+), 4096 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcollectioncolumn.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcrystal_structure.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_correlation.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_eels.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfabrication.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) delete mode 100644 contributed_definitions/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml delete mode 100644 contributed_definitions/NXem_msr.nxdl.xml delete mode 100644 contributed_definitions/NXem_sim.nxdl.xml delete mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml delete mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml rename contributed_definitions/{NXcs_mm_obj.nxdl.xml => NXprogram.nxdl.xml} (57%) rename contributed_definitions/{NXcs_cpu_obj.nxdl.xml => NXregistration.nxdl.xml} (53%) delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.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_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5e5e8860 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + 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. + The cardinality of the set, i.e. the number of cylinders or cones. - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders in Euclidean space. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. - + + + + + + + - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. - + + + + Integer used to distinguish members for explicit indexing. + + - - - + - Radius of the cylinder if all have the same radius. + The geometric center of each member. + + + + - + - Radii of the cylinder. + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. - + + + + + + + + - + - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + - + - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + - Lateral surface area + Interior volume of each cylinder - + - + - Area of the upper cap of each cylinder. + Lateral surface area - + - + - Area of the lower cap of each cylinder. + Area of the upper and the lower cap of each cylinder respectively. - + + - + - Sum of upper and lower cap areas and lateral surface area - of each cylinder. + Cap and lateral surface area for each cylinder. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 58d4d5796..e50192cf8 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,10 +39,46 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> - Computational geometry description of a set of spheres. + Computational geometry description of a set of spheres in Euclidean space. - Each sphere can have a different radius but all need to have finite volume. + Each sphere can have a different radius. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + In the case that all spheres have the same radius. @@ -54,7 +89,32 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system.nxdl.xml rename to base_classes/NXcoordinate_system.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcrystal_structure.nxdl.xml rename to base_classes/NXcrystal_structure.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_correlation.nxdl.xml rename to base_classes/NXem_correlation.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eels.nxdl.xml rename to base_classes/NXem_eels.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b290908..84a36254c 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index e5e5e8860..000000000 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index c3636c6b3..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 68b87e47e..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,135 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index e9d15f5b0..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,81 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From afddfc9a9db9213710197c65406a7514d7b1a337 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 160/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_sphere_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 128 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 21 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 13 +- base_classes/NXcg_sphere_set.nxdl.xml | 74 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ .../NXms_odf_set.nxdl.xml | 28 +- contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 95 files changed, 7130 insertions(+), 8091 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXms_odf_set.nxdl.xml (53%) create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - + 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 cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius 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 lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml index 6314db342..244290a81 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/base_classes/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,6 +54,17 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + Dimensionality of the primitives described. + + @@ -176,7 +187,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml index 4cc765fd8..f04bdaad8 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/base_classes/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml index da55b2530..5aebe0d78 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml similarity index 53% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXms_odf_set.nxdl.xml index 9f38b2d7b..d41a609a8 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. - - - - Principle type of the pump. - - - - - - - - - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From 77df8605846107d0ab1365cc6b651055ea88b426 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 161/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXpump.nxdl.xml | 43 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 70 files changed, 8544 insertions(+), 179 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index bedba8b6f..0b1f581a8 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 000000000..9f38b2d7b --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From e1d56c926299bcd0a2644d42ed1e1017875306dd Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 162/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- base_classes/NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 365 insertions(+), 186 deletions(-) create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index e05baf1ea..1f41de1e8 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 8b1283474..58d4d5796 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..dd5f5246d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From e58b2f9f6cae53613bd8454919f8c1c0e865adcb Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 165/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 7 files changed, 15 insertions(+), 311 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 038827f70..ad33f94aa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 1f41de1e8..e05baf1ea 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml index 58d4d5796..8b1283474 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/base_classes/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 94a5225a2d34a41d5e9d910f3d9f7544188cbcb9 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 167/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 39568c6a8b8c0047224bde29f1e6562901c84e23 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 169/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXfabrication.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcs_gpu_sys.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpump.nxdl.xml | 43 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 - .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ .../NXcs_cpu_obj.nxdl.xml | 27 +- ...gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} | 29 +- .../NXcs_gpu_obj.nxdl.xml | 27 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 36 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + .../{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} | 32 +- contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 52 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- ...odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} | 14 +- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- .../{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} | 21 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 92 files changed, 5047 insertions(+), 9917 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXcs_cpu_obj.nxdl.xml (61%) rename contributed_definitions/{NXcs_gpu_sys.nxdl.xml => NXcs_cpu_sys.nxdl.xml} (65%) rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXcs_gpu_obj.nxdl.xml (67%) rename base_classes/NXfabrication.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (57%) create mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml rename contributed_definitions/{NXem_adf.nxdl.xml => NXem_img.nxdl.xml} (75%) create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename contributed_definitions/{NXms_odf_set.nxdl.xml => NXms_ipf_set.nxdl.xml} (80%) delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename contributed_definitions/{NXms_pf_set.nxdl.xml => NXroi.nxdl.xml} (72%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 61% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index e5f40c95a..6ce5370a3 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Computer science description of a (central) processing unit (C)PU of a computer. - + + + Given name of the CPU. Users should be as specific as possible. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml similarity index 65% rename from contributed_definitions/NXcs_gpu_sys.nxdl.xml rename to contributed_definitions/NXcs_cpu_sys.nxdl.xml index e7fedabd4..0de162c66 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a system of coprocessor or graphics processors. + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - + Granularizing at the socket level. - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml similarity index 67% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXcs_gpu_obj.nxdl.xml index bc6d4c291..3c5b6c26a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Component of an instrument to store or place objects and specimens. - - + + - Given name/alias. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a graphic processing unit (GPU) of a computer. + + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - - - Details about a component as defined by its manufacturer. - - + + - Company name of the manufacturer. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of a memory in a memory system. + + - Version or model of the component named by the manufacturer. + Qualifier for the type of random access memory. - + + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + Total amount of data which the medium can hold. - + + - Free-text list with eventually multiple terms of - functionalities which the component offers. + Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml similarity index 75% rename from contributed_definitions/NXem_adf.nxdl.xml rename to contributed_definitions/NXem_img.nxdl.xml index 110642413..ebf17380a 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -40,7 +40,7 @@ - Base class method-specific for annular dark field imaging. + Base class for method-specific generic imaging. In the majority of cases simple d-dimensional regular scan patterns are used to probe a region-of-interest (ROI). Examples can be single point aka spot @@ -50,16 +50,14 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - + + + Which imaging mode was used? + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index a482480c8..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index 98919c2ed..000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 80% rename from contributed_definitions/NXms_odf_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index c21aa3698..776eb0a6c 100644 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ - + - Base class to group multiple :ref:`NXms_odf` instances. + Base class to group multiple :ref:`NXms_ipf` instances. - A collection of orientation distribution function approximations. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 72% rename from contributed_definitions/NXms_pf_set.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index 14a4061d6..b77834bb6 100644 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - + - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. + Base class to describe a region-of-interest analyzed. - + + + Details about processing steps. + + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From c5cc88f36c8d9677a3e7576df1e32ac1c8dc17ba Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 170/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcollectioncolumn.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXchamber.nxdl.xml | 37 +- .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + contributed_definitions/NXdeflector.nxdl.xml | 92 + .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 59 files changed, 8784 insertions(+), 126 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXchamber.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Component of an instrument to store or place objects and specimens. - + + + Given name/alias. + + + - Details about processing steps. + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. - - - - - + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a8dcb8369..657fda03a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 3c5b6c26a..b0a9b0e77 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 000000000..abdea5bbb --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the deflector. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893..c3b1f87a8 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 000000000..99a19f2e3 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c..9b77945cd 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 5b38c9ba218a41e73aafef245a3800ca03623919 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 171/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- base_classes/NXprogram.nxdl.xml | 4 +- base_classes/NXregistration.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 4 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 43 +++++++++++++++++++ contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 85 files changed, 211 insertions(+), 168 deletions(-) create mode 100644 contributed_definitions/NXpump.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + + diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index c5a274be4..94857e74c 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index e05baf1ea..1f41de1e8 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..dd5f5246d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From de6620b4e874fd6bb85e58a37c74a8a01330882e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 174/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcomponent_em.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_odf_set.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_pf_set.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 1f41de1e8..e05baf1ea 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 18cf0bda8980303442c6ea77e98a0996b92b430c Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 176/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_adf.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_conventions_ebsd.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_r_set_diff.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_ipf.nxdl.xml # contributed_definitions/NXms_mtex_config.nxdl.xml # contributed_definitions/NXms_odf.nxdl.xml # contributed_definitions/NXms_pf.nxdl.xml # contributed_definitions/NXms_recon.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a2329321..000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From f4c77e4819f4e880deedb17541f5834b9a862114 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 178/198] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach # Conflicts: # applications/NXapm.nxdl.xml # applications/NXem.nxdl.xml # base_classes/NXaberration.nxdl.xml # base_classes/NXcg_alpha_complex.nxdl.xml # base_classes/NXcg_cylinder_set.nxdl.xml # base_classes/NXcg_geodesic_mesh.nxdl.xml # base_classes/NXcg_grid.nxdl.xml # base_classes/NXcg_half_edge_data_structure.nxdl.xml # base_classes/NXcg_marching_cubes.nxdl.xml # base_classes/NXcg_polyline_set.nxdl.xml # base_classes/NXcg_triangulated_surface_mesh.nxdl.xml # base_classes/NXcg_unit_normal_set.nxdl.xml # base_classes/NXchamber.nxdl.xml # base_classes/NXcoordinate_system_set.nxdl.xml # base_classes/NXcorrector_cs.nxdl.xml # base_classes/NXcs_computer.nxdl.xml # base_classes/NXcs_filter_boolean_mask.nxdl.xml # base_classes/NXcs_prng.nxdl.xml # base_classes/NXcs_profiling.nxdl.xml # base_classes/NXcs_profiling_event.nxdl.xml # base_classes/NXdeflector.nxdl.xml # base_classes/NXebeam_column.nxdl.xml # base_classes/NXem_ebsd.nxdl.xml # base_classes/NXevent_data_em.nxdl.xml # base_classes/NXevent_data_em_set.nxdl.xml # base_classes/NXibeam_column.nxdl.xml # base_classes/NXimage_set.nxdl.xml # base_classes/NXion.nxdl.xml # base_classes/NXlens_em.nxdl.xml # base_classes/NXoptical_system_em.nxdl.xml # base_classes/NXpump.nxdl.xml # base_classes/NXregistration.nxdl.xml # base_classes/NXscanbox_em.nxdl.xml # base_classes/NXspectrum_set.nxdl.xml # base_classes/NXstage_lab.nxdl.xml # contributed_definitions/NXaberration_model.nxdl.xml # contributed_definitions/NXaberration_model_ceos.nxdl.xml # contributed_definitions/NXaberration_model_nion.nxdl.xml # contributed_definitions/NXaperture_em.nxdl.xml # contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polygon_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcg_tetrahedron_set.nxdl.xml # contributed_definitions/NXcg_triangle_set.nxdl.xml # contributed_definitions/NXcs_gpu_obj.nxdl.xml # contributed_definitions/NXcs_io_obj.nxdl.xml # contributed_definitions/NXcs_io_sys.nxdl.xml # contributed_definitions/NXcs_mm_sys.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXgraph_node_set.nxdl.xml # contributed_definitions/NXgraph_root.nxdl.xml # contributed_definitions/NXimage_set_em_adf.nxdl.xml # contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXisocontour.nxdl.xml # contributed_definitions/NXms.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXms_score_results.nxdl.xml # contributed_definitions/NXorientation_set.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXspectrum_set_em_eels.nxdl.xml # contributed_definitions/NXspectrum_set_em_xray.nxdl.xml # contributed_definitions/nyaml/NXaberration.yaml # contributed_definitions/nyaml/NXaberration_model.yaml # contributed_definitions/nyaml/NXaberration_model_ceos.yaml # contributed_definitions/nyaml/NXaberration_model_nion.yaml # contributed_definitions/nyaml/NXaperture_em.yaml # contributed_definitions/nyaml/NXapm.yaml # contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml # contributed_definitions/nyaml/NXcg_alpha_complex.yaml # contributed_definitions/nyaml/NXcg_cylinder_set.yaml # contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml # contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml # contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml # contributed_definitions/nyaml/NXcg_grid.yaml # contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml # contributed_definitions/nyaml/NXcg_hexahedron_set.yaml # contributed_definitions/nyaml/NXcg_marching_cubes.yaml # contributed_definitions/nyaml/NXcg_parallelogram_set.yaml # contributed_definitions/nyaml/NXcg_point_set.yaml # contributed_definitions/nyaml/NXcg_polygon_set.yaml # contributed_definitions/nyaml/NXcg_polyhedron_set.yaml # contributed_definitions/nyaml/NXcg_polyline_set.yaml # contributed_definitions/nyaml/NXcg_roi_set.yaml # contributed_definitions/nyaml/NXcg_sphere_set.yaml # contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml # contributed_definitions/nyaml/NXcg_triangle_set.yaml # contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml # contributed_definitions/nyaml/NXcg_unit_normal_set.yaml # contributed_definitions/nyaml/NXchamber.yaml # contributed_definitions/nyaml/NXcoordinate_system_set.yaml # contributed_definitions/nyaml/NXcorrector_cs.yaml # contributed_definitions/nyaml/NXcs_computer.yaml # contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml # contributed_definitions/nyaml/NXcs_io_obj.yaml # contributed_definitions/nyaml/NXcs_io_sys.yaml # contributed_definitions/nyaml/NXcs_mm_sys.yaml # contributed_definitions/nyaml/NXcs_prng.yaml # contributed_definitions/nyaml/NXcs_profiling.yaml # contributed_definitions/nyaml/NXcs_profiling_event.yaml # contributed_definitions/nyaml/NXdeflector.yaml # contributed_definitions/nyaml/NXebeam_column.yaml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_ebsd.yaml # contributed_definitions/nyaml/NXevent_data_em.yaml # contributed_definitions/nyaml/NXevent_data_em_set.yaml # contributed_definitions/nyaml/NXfabrication.yaml # contributed_definitions/nyaml/NXgraph_edge_set.yaml # contributed_definitions/nyaml/NXgraph_node_set.yaml # contributed_definitions/nyaml/NXgraph_root.yaml # contributed_definitions/nyaml/NXibeam_column.yaml # contributed_definitions/nyaml/NXimage_set.yaml # contributed_definitions/nyaml/NXinteraction_vol_em.yaml # contributed_definitions/nyaml/NXion.yaml # contributed_definitions/nyaml/NXisocontour.yaml # contributed_definitions/nyaml/NXlens_em.yaml # contributed_definitions/nyaml/NXms.yaml # contributed_definitions/nyaml/NXms_feature_set.yaml # contributed_definitions/nyaml/NXms_score_results.yaml # contributed_definitions/nyaml/NXoptical_system_em.yaml # contributed_definitions/nyaml/NXpump.yaml # contributed_definitions/nyaml/NXrotation_set.yaml # contributed_definitions/nyaml/NXscanbox_em.yaml # contributed_definitions/nyaml/NXspectrum_set.yaml # contributed_definitions/nyaml/NXstage_lab.yaml # dev_tools/tests/test_nxdl_utils.py # manual/source/classes/contributed_definitions/cgms-structure.rst # manual/source/classes/contributed_definitions/em-structure.rst # manual/source/classes/contributed_definitions/icme-structure.rst --- applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- base_classes/NXaberration.nxdl.xml | 55 - base_classes/NXcg_alpha_complex.nxdl.xml | 6 +- base_classes/NXcg_cylinder_set.nxdl.xml | 6 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 6 +- base_classes/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_marching_cubes.nxdl.xml | 6 +- base_classes/NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 6 +- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdeflector.nxdl.xml | 92 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXregistration.nxdl.xml | 55 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_primitive_set.nxdl.xml | 212 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 ++ .../NXcrystal_structure.nxdl.xml | 280 +++ ...gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} | 12 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- .../NXcs_mm_obj.nxdl.xml | 40 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++++ .../NXem_conventions_ebsd.nxdl.xml | 230 ++ .../NXem_correlation.nxdl.xml | 245 ++ contributed_definitions/NXem_eds.nxdl.xml | 144 ++ contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 247 ++ .../NXimage_r_set.nxdl.xml | 56 +- .../NXimage_r_set_diff.nxdl.xml | 179 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++++ .../NXms_ipf_set.nxdl.xml | 19 +- .../NXms_mtex_config.nxdl.xml | 310 +++ contributed_definitions/NXms_odf.nxdl.xml | 171 ++ contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++++ .../NXms_score_results.nxdl.xml | 22 +- .../NXroi.nxdl.xml | 26 +- .../nyaml/NXcg_primitive_set.yaml | 136 ++ .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcrystal_structure.yaml | 178 ++ contributed_definitions/nyaml/NXem_base.yaml | 297 +++ .../nyaml/NXem_correlation.yaml | 191 ++ contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + contributed_definitions/nyaml/NXroi.yaml | 9 + 95 files changed, 7199 insertions(+), 7981 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXregistration.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml rename contributed_definitions/{NXcs_gpu_obj.nxdl.xml => NXcs_cpu_obj.nxdl.xml} (83%) create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml rename base_classes/NXpump.nxdl.xml => contributed_definitions/NXcs_mm_obj.nxdl.xml (56%) create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml rename base_classes/NXimage_set.nxdl.xml => contributed_definitions/NXimage_r_set.nxdl.xml (61%) create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml rename base_classes/NXevent_data_em_set.nxdl.xml => contributed_definitions/NXms_ipf_set.nxdl.xml (67%) create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml rename base_classes/NXchamber.nxdl.xml => contributed_definitions/NXroi.nxdl.xml (63%) create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..edf367ba0 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index 01db33f5c..000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml deleted file mode 100644 index a33ba3b50..000000000 --- a/base_classes/NXregistration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 000000000..ac451bdc6 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the 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). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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 of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + 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 length of one characteristic edge + within 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. + + + + + + + + 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. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 000000000..bedba8b6f --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..a8dcb8369 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second 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. + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 000000000..4baccda13 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + 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. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml similarity index 83% rename from contributed_definitions/NXcs_gpu_obj.nxdl.xml rename to contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8353ca814..6ce5370a3 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a graphic processing unit (GPU) of a computer. + Computer science description of a (central) processing unit (C)PU of a computer. - Given name of the GPU. Users should be as specific as possible. + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 000000000..0de162c66 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 000000000..217f1adb2 --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 59c620e7b..5608c9f88 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -2,9 +2,9 @@ - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Device to reduce an atmosphere to a controlled remaining pressure level. + Computer science description of a memory in a memory system. - - + + + Qualifier for the type of random access memory. + + + + - Principle type of the pump. + Total amount of data which the medium can hold. - - - - - - - + + + + Given name to the I/O unit. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index 6fed931cb..d9c6779fd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 000000000..479819893 --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :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 the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. 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 parent_identifier. + + 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. + + + + + 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 parent_identifier or walk through + eventually deeply nested groups in 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 an + :ref:`NXinteraction_vol_em` within 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 although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 000000000..8a19f1e29 --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 000000000..58c0f6825 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + 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 new file mode 100644 index 000000000..735bfe897 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + 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. + + + + + + + + + + List of the names of identified elements. + + + + + + + + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 000000000..c355f6fd6 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 000000000..ebf17380a --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 000000000..086d4833d --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 000000000..a6442b1e2 --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + 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. + + + + + + + + + + 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. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 000000000..f5f10b1b9 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of 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 + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `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/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/base_classes/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml similarity index 61% rename from base_classes/NXimage_set.nxdl.xml rename to contributed_definitions/NXimage_r_set.nxdl.xml index 121163ce0..3ef371809 100644 --- a/base_classes/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -40,42 +40,14 @@ - Container for reporting a set of images taken. + Specialized base class container for reporting a set of images in real space. - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - + Image (stack). - + Image intensity values. @@ -85,14 +57,14 @@ - + Image identifier - + Image identifier. @@ -100,12 +72,12 @@ - Pixel coordinate center of mass along y direction. + Pixel coordinate center along y direction. - + Coordinate along y direction. @@ -113,12 +85,12 @@ - Pixel coordinate center of mass along x direction. + Pixel coordinate center along x direction. - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 000000000..c9ff02c0d --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 000000000..49568b0ac --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when 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. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier 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:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools 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 + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into 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 each point in + the fundamental zone a color. + + 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) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the 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. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml similarity index 67% rename from base_classes/NXevent_data_em_set.nxdl.xml rename to contributed_definitions/NXms_ipf_set.nxdl.xml index e5f40c95a..776eb0a6c 100644 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class to group multiple :ref:`NXms_ipf` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + A collection of inverse pole figure approximations. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 000000000..a810d12b3 --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 000000000..988034557 --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 000000000..d41a609a8 --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 000000000..9a627ac62 --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + 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. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 000000000..3ca5fc000 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 000000000..99e629ba2 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from 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]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml similarity index 63% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXroi.nxdl.xml index bc6d4c291..b77834bb6 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class to describe a region-of-interest analyzed. - - - Given name/alias. - - - + - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. + Details about processing steps. - - + + diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 000000000..586929596 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +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). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from 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. + + 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. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + 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. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 000000000..b21939900 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +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): + doc: | + 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*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + 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. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second 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. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 000000000..796ac83d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 000000000..2de8081a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + 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 that writes these :ref:`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. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective 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 through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval 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. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + 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 the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! 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 only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + 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. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + 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 parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + 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. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 000000000..2acf65ec8 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 000000000..9a5a97fcd --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + 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 NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 000000000..4e5c69fe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 000000000..8c257d121 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). 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. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 000000000..afe91de97 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 000000000..16c349ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_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. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (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. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 000000000..81fe20db1 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 000000000..a8ba2426a --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): From bb41c43523f43784ab17dc4fda1d47d7dc67076e Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 179/198] Make nxdl # Conflicts: # base_classes/NXcg_roi_set.nxdl.xml # base_classes/NXcollectioncolumn.nxdl.xml # base_classes/NXem_img.nxdl.xml # base_classes/NXem_method.nxdl.xml # base_classes/NXprogram.nxdl.xml # base_classes/NXroi.nxdl.xml # base_classes/NXroot.nxdl.xml # contributed_definitions/NXaberration.nxdl.xml # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcalibration.nxdl.xml # contributed_definitions/NXcoordinate_system_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXcs_computer.nxdl.xml # contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml # contributed_definitions/NXcs_prng.nxdl.xml # contributed_definitions/NXcs_profiling.nxdl.xml # contributed_definitions/NXcs_profiling_event.nxdl.xml # contributed_definitions/NXdeflector.nxdl.xml # contributed_definitions/NXebeam_column.nxdl.xml # contributed_definitions/NXelectronanalyser.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXenergydispersion.nxdl.xml # contributed_definitions/NXevent_data_em.nxdl.xml # contributed_definitions/NXevent_data_em_set.nxdl.xml # contributed_definitions/NXibeam_column.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXlens_em.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXpump.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 2 +- base_classes/NXcg_cylinder_set.nxdl.xml | 2 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 2 +- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- base_classes/NXcg_marching_cubes.nxdl.xml | 2 +- base_classes/NXcg_polyline_set.nxdl.xml | 2 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 2 +- base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - contributed_definitions/NXaberration.nxdl.xml | 55 + contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_primitive_set.nxdl.xml | 2 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 104 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 85 + .../NXcs_profiling.nxdl.xml | 149 ++ .../NXcs_profiling_event.nxdl.xml | 95 + .../NXdeflector.nxdl.xml | 70 +- .../NXebeam_column.nxdl.xml | 109 + .../NXelectronanalyser.nxdl.xml | 157 ++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 20 +- .../NXibeam_column.nxdl.xml | 144 ++ .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 83 + .../NXpump.nxdl.xml | 41 +- contributed_definitions/NXroi.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXspectrum_set.nxdl.xml | 162 ++ contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ 69 files changed, 8501 insertions(+), 228 deletions(-) delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXaberration.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml rename base_classes/NXcollectioncolumn.nxdl.xml => contributed_definitions/NXdeflector.nxdl.xml (54%) create mode 100644 contributed_definitions/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) create mode 100644 contributed_definitions/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml rename base_classes/NXprogram.nxdl.xml => contributed_definitions/NXpump.nxdl.xml (53%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index edf367ba0..40d123ffb 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -3,7 +3,7 @@ - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 000000000..3c784de1b --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Quantified aberration coefficient in an aberration_model. + + + + + Confidence + + + + + How was the uncertainty quantified e.g. via the 95% confidence interval. + + + + + 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. + + + + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 000000000..6f02ae180 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + 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 available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + 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 specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + 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. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 000000000..8dd7a6da5 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc6..3753f322a 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -3,7 +3,7 @@ + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 000000000..fcca05d7a --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 4baccda13..0f6810ed5 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 6ce5370a3..2da131b01 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml index 217f1adb2..38c716126 100644 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 000000000..97105a1b2 --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,149 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + + Path to the directory from which the tool was called. + + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + + + + + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 000000000..195dee88c --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + + + + + Free-text description what was monitored/executed during the event. + + + + + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + + + + + Number of processes used (max) during the execution of this event. + + + + + Number of threads used (max) during the execution of this event. + + + + + Number of GPUs used (max) during the execution of this event. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 54% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 5348d55b5..abdea5bbb 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -21,56 +21,60 @@ # # For further information, see http://www.nexusformat.org --> - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Deflectors as they are used e.g. in an electron analyser. - + - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Qualitative type of deflector with respect to the number of pole pieces + + + + + + - + - Voltage applied to the extractor lens + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. - + - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. + Name of the manufacturer who built/constructed the deflector. - + - Distance between sample and detector entrance + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Labelling of the lens setting in use. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - The space projected in the angularly dispersive directions, real or reciprocal + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - - - - - + - The magnification of the electron lens assembly. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. @@ -85,20 +89,4 @@ the reference coordinate system. - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 000000000..03b54b779 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 000000000..db991447d --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 000000000..ad33f94aa --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699c..332b4f2bc 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -3,7 +3,7 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe897..daf3b9b9e 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 000000000..4192c4879 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + 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. + + + + + + + + + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 94857e74c..7ec26670c 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class to describe a region-of-interest analyzed. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - - - Details about processing steps. - - - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 000000000..0377b93f4 --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + + Average/nominal brightness + + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99..f4d146af1 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 000000000..92be5ae59 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 000000000..c2bfe957c --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac..70c575b07 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -3,7 +3,7 @@ + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 53% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index aaad75e98..9f38b2d7b 100644 --- a/base_classes/NXprogram.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Base class to describe a software tool or library. + Device to reduce an atmosphere to a controlled remaining pressure level. - + + - Given name of the program. Program can be a commercial one a script, - or a library or a library component. + Principle type of the pump. - - - 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/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml index b77834bb6..c5a274be4 100644 --- a/contributed_definitions/NXroi.nxdl.xml +++ b/contributed_definitions/NXroi.nxdl.xml @@ -3,7 +3,7 @@ + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 000000000..9ca3aab34 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 000000000..7b916d272 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + From 50d1602ba5472d1a1ddaac80f87a145012225393 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:32:56 +0100 Subject: [PATCH 180/198] Whitespace above and below copyright removed (new nyaml version) # Conflicts: # base_classes/NXroot.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml --- base_classes/NXcg_alpha_complex.nxdl.xml | 4 +- base_classes/NXcg_cylinder_set.nxdl.xml | 4 +- base_classes/NXcg_geodesic_mesh.nxdl.xml | 4 +- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- base_classes/NXcg_marching_cubes.nxdl.xml | 4 +- base_classes/NXcg_polyline_set.nxdl.xml | 4 +- base_classes/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- base_classes/NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXaberration.nxdl.xml | 4 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 4 +- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 4 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_primitive_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 40 ++++++ .../NXcomponent_em.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 4 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcrystal_structure.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 4 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 4 +- .../NXcs_profiling.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 4 +- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_adf.nxdl.xml | 4 +- contributed_definitions/NXem_base.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 4 +- contributed_definitions/NXem_ebsd.nxdl.xml | 4 +- contributed_definitions/NXem_eds.nxdl.xml | 4 +- contributed_definitions/NXem_eels.nxdl.xml | 4 +- contributed_definitions/NXem_img.nxdl.xml | 4 +- contributed_definitions/NXem_method.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 4 +- contributed_definitions/NXem_sim.nxdl.xml | 4 +- .../NXenergydispersion.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 4 +- .../NXevent_data_em_set.nxdl.xml | 4 +- .../NXfabrication.nxdl.xml | 51 +++++++ .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 4 +- .../NXimage_r_set.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 4 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++++++++++++++++++ contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 4 +- .../NXms_feature_set.nxdl.xml | 4 +- contributed_definitions/NXms_ipf.nxdl.xml | 4 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 4 +- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 4 +- contributed_definitions/NXms_odf_set.nxdl.xml | 4 +- contributed_definitions/NXms_pf.nxdl.xml | 4 +- contributed_definitions/NXms_pf_set.nxdl.xml | 4 +- contributed_definitions/NXms_recon.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 4 +- .../NXoptical_system_em.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- 95 files changed, 403 insertions(+), 184 deletions(-) create mode 100644 contributed_definitions/NXchamber.nxdl.xml create mode 100644 contributed_definitions/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 40d123ffb..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -2,9 +2,9 @@ + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0b1f581a8..a68436e9b 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c..0712d1eb2 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 99a19f2e3..fc3ca7176 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f86b09082..6f02ae180 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index e05baf1ea..1f41de1e8 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index ab3a8afaf..acc4bc87d 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 03f5ff709..1de66d16b 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index f317e76cb..df8c1ca1a 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..9446cdd8b 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index e5bb83807..f87f5f7ac 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..894250e15 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..26e307d08 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..d07536588 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 21470b34f..6da20e548 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 878a5c3ff..002c112f9 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 3a856635b..301192ac1 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,21 +48,12 @@ - + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 19ffa5559..59f5cffc0 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -83,7 +83,7 @@ If all ellipsoids in the set have the same half-axes. - + @@ -92,7 +92,7 @@ In the case that ellipsoids have different radii use this field instead of half_axes_radius. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index ccdb4f7ec..ea8faee3e 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ The accumulated length of the polygon edge. - + @@ -132,7 +132,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +144,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 75990de50..e445ff1e7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -103,7 +103,7 @@ for clean graph-based descriptions of polyhedra.--> are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc..93b35cfef 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 16cf829ea..abc88b051 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -89,7 +89,7 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index a00b1464b..d70836aee 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 6e5ad2fc7..d1fece068 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956..97f1ebd1a 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 89dc04ff0..fcca05d7a 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 2ee961538..4ffc77ba8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 3b2d4be1d..9d674f6b2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 5c1bea608..f061f7f58 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - 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 that writes these :ref:`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 configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective 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 through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval 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. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :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 the start_time and end_time should be used together. - - - - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - - - Possibility to store a collection of data artifacts - associated with the experiment. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! 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 only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. 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 parent_identifier. - - 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. - - - - - 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 parent_identifier or walk through - eventually deeply nested groups in 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 an - :ref:`NXinteraction_vol_em` within 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 although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aa..b00b7ea92 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b51..e9bd12b89 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e6cfd1c80..aa3dd46be 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - - - - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - - - - Number of X-ray photon energy (bins), the fastest direction. - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - 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. - - - - - - - - - - List of the names of identified elements. - - - - - - - - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index d42af5a47..926e5acb6 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -46,7 +46,7 @@ specialized to include EELS-specific post-processing--> \@axis_x_indices: 1 \@axis_y_indices: 0--> - + @@ -64,7 +64,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 0712d1eb2..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `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/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - Image stack. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Image hyperstack. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 86a6c6311..000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed..9bb45544f 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fc3ca7176..99a19f2e3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,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. - + @@ -172,7 +170,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. - + @@ -181,7 +179,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. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132be..721aeca84 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd7..90c9ae1c1 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b..7425c8a82 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239..390f03969 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 56ff4e25f..0f753001e 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..dd5f5246d 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 196deb635..9ca3aab34 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -2,9 +2,9 @@ second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 3dc1ce5948eff5edeb11f681e7dacf369a1958db Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 183/198] Recompiled NXDLs from yaml using nyaml==0.0.9 # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXcg_ellipsoid_set.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_polyhedron_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXchamber.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXem.nxdl.xml # contributed_definitions/NXem_base.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXfabrication.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXidentifier.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXimage_set.nxdl.xml # contributed_definitions/NXinteraction_vol_em.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXserialized.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXxrd.nxdl.xml # contributed_definitions/NXxrd_pan.nxdl.xml # contributed_definitions/nyaml/NXem.yaml # contributed_definitions/nyaml/NXem_base.yaml --- .../NXcg_ellipsoid_set.nxdl.xml | 8 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 10 +- .../NXcg_sphere_set.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 4 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 297 ------------------ 8 files changed, 18 insertions(+), 314 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 59f5cffc0..38a448a0e 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index e445ff1e7..e3a6e99fe 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ are counted for each polyhedron. This field can be used to interpret the array/field with the individual area values for each face. - + @@ -111,7 +111,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of the four triangular faces of each tetrahedron. - + @@ -126,7 +126,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index abc88b051..e50192cf8 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -79,7 +79,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge. - + @@ -124,7 +124,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Each list is sorted in descending order. Unused values up to n_ivec_max are nullified. - + @@ -134,7 +134,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. - + @@ -142,7 +142,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclids for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of the nuclid with the shortest half life. - + diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml index 1f41de1e8..e05baf1ea 100644 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ b/base_classes/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -105,7 +105,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -120,7 +120,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -134,7 +134,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml index acc4bc87d..ab3a8afaf 100644 --- a/base_classes/NXapm_ranging.nxdl.xml +++ b/base_classes/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml index 1de66d16b..03f5ff709 100644 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ b/base_classes/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a..f317e76cb 100644 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ b/base_classes/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 9446cdd8b..b6a466bc5 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml index f87f5f7ac..e5bb83807 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/base_classes/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 894250e15..4d5aced5f 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 26e307d08..40213352e 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index d07536588..64a002f86 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml index 6da20e548..21470b34f 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml index 002c112f9..878a5c3ff 100644 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ b/base_classes/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml index 301192ac1..3a856635b 100644 --- a/base_classes/NXpulser_apm.nxdl.xml +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2bfd59130..31a71c572 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -121,7 +123,7 @@ properties of the polygon primitives--> The accumulated length of the polygon edge. - + @@ -132,7 +134,7 @@ properties of the polygon primitives--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -144,7 +146,7 @@ properties of the polygon primitives--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfef..e8cb457bc 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index d70836aee..a00b1464b 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -93,7 +93,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the four triangular faces of each tetrahedron. - + @@ -102,7 +102,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index d1fece068..6e5ad2fc7 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -99,7 +99,7 @@ properties of triangles--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -110,7 +110,7 @@ properties of triangles--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a..494b92956 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed6080..921663cef 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 4ffc77ba8..2ee961538 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -86,7 +86,7 @@ The unsigned integer array representing the content of the mask. If padding is used the padded bits have to be set to 0. - + @@ -97,7 +97,7 @@ to the first identifier, the second bit in the mask to the second identifier and so on and so forth. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9d674f6b2..3b2d4be1d 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -80,7 +80,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -88,7 +88,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ad33f94aa..0509b9086 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -517,12 +517,14 @@ NEW ISSUE: will be added by yaml2nxdl automatically--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 193600031..110642413 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea92..d2d7456aa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89..95a644b51 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 02d01322f..fb0429164 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -60,7 +60,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -72,7 +72,7 @@ instances which are groups like NXgraph_node_set could have an is_a qualifier reading NXgraph_node_set. - + @@ -80,7 +80,7 @@ A human-readable label/caption/tag of the graph. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f..98919c2ed 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index aacbc932d..b7fcbbabf 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -56,7 +56,7 @@ matching 1, 5 or 6 will be processed. All other entries will be filtered out. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 5e991f25b..f75c6e8f2 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -277,10 +277,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f70595..0be3dc81e 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,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. - + @@ -170,7 +172,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. - + @@ -179,7 +181,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. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca84..90e4132be 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c1..3e9d11dd7 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a82..44db61d7b 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f03969..f44d34239 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index c1bd2217e..77c73b42f 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -312,9 +312,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -691,21 +693,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246d..e9d893e28 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3775e840..e3c52b3ef 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -138,7 +138,7 @@ Should be defined by the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa..0310e9f26 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From deab0fec4a29fcb56ac7ba89e08c95fce90b6ff0 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 185/198] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls # Conflicts: # contributed_definitions/NXapm.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml # contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml # contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml # contributed_definitions/NXcg_face_list_data_structure.nxdl.xml # contributed_definitions/NXcg_hexahedron_set.nxdl.xml # contributed_definitions/NXcg_parallelogram_set.nxdl.xml # contributed_definitions/NXcg_point_set.nxdl.xml # contributed_definitions/NXcg_sphere_set.nxdl.xml # contributed_definitions/NXcorrector_cs.nxdl.xml # contributed_definitions/NXdelocalization.nxdl.xml # contributed_definitions/NXem_conventions.nxdl.xml # contributed_definitions/NXem_ebsd.nxdl.xml # contributed_definitions/NXem_eds.nxdl.xml # contributed_definitions/NXgraph_edge_set.nxdl.xml # contributed_definitions/NXimage_c_set.nxdl.xml # contributed_definitions/NXimage_r_set.nxdl.xml # contributed_definitions/NXion.nxdl.xml # contributed_definitions/NXms_feature_set.nxdl.xml # contributed_definitions/NXoptical_system_em.nxdl.xml # contributed_definitions/NXrotation_set.nxdl.xml # contributed_definitions/NXscanbox_em.nxdl.xml # contributed_definitions/NXspectrum_set.nxdl.xml # contributed_definitions/NXstage_lab.nxdl.xml --- contributed_definitions/NXcg_polygon_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 31a71c572..4969f2e83 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -97,7 +97,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand Integer used to distinguish polygons for explicit indexing. - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index e3c52b3ef..7b916d272 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 4969f2e83..000000000 --- a/contributed_definitions/NXcg_polygon_set.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 either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc..000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the 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). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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 of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - 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 length of one characteristic edge - within 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. - - - - - - - - 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. - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index a00b1464b..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 6e5ad2fc7..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae840..000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb648..000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84..000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_obj.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml index 4e69e64e1..e92363efe 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a memory in a memory system. + Base class to describe a software tool or library. - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - + - Given name to the I/O unit. + 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/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 53% rename from contributed_definitions/NXcs_cpu_obj.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml index 8a2329321..2ae999351 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a (central) processing unit (C)PU of a computer. + Describes image registration procedures. - + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + - Given name of the CPU. Users should be as specific as possible. + Description of the procedures employed. - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596..000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +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). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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. - - 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. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - 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. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b21939900..000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -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): - doc: | - 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*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - 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. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second 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. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3..000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec8..000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd..000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - 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 NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4..000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121..000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de97..000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca5..000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_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. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (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. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1..000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426a..000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): From 6267928610be831b229f3f69e697ad0e743a03a5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 24 Sep 2024 09:10:33 +0200 Subject: [PATCH 187/198] revert unintentional changes from cherry-pick --- Makefile | 2 - applications/NXapm.nxdl.xml | 1696 -------------- applications/NXem.nxdl.xml | 2036 ----------------- applications/NXmpes.nxdl.xml | 371 --- base_classes/NXaberration.nxdl.xml | 55 - .../NXapm_charge_state_analysis.nxdl.xml | 157 -- base_classes/NXapm_hit_finding.nxdl.xml | 148 -- base_classes/NXapm_msr.nxdl.xml | 176 -- base_classes/NXapm_ranging.nxdl.xml | 111 - base_classes/NXapm_reconstruction.nxdl.xml | 123 - base_classes/NXapm_volt_and_bowl.nxdl.xml | 69 - base_classes/NXcalibration.nxdl.xml | 111 - base_classes/NXchamber.nxdl.xml | 40 - base_classes/NXchemical_composition.nxdl.xml | 69 - base_classes/NXcoordinate_system.nxdl.xml | 143 -- base_classes/NXcoordinate_system_set.nxdl.xml | 137 -- base_classes/NXcorrector_cs.nxdl.xml | 95 - base_classes/NXcrystal_structure.nxdl.xml | 280 --- base_classes/NXcs_computer.nxdl.xml | 80 - .../NXcs_filter_boolean_mask.nxdl.xml | 104 - base_classes/NXcs_prng.nxdl.xml | 85 - base_classes/NXcs_profiling.nxdl.xml | 149 -- base_classes/NXcs_profiling_event.nxdl.xml | 95 - base_classes/NXdistortion.nxdl.xml | 111 - base_classes/NXebeam_column.nxdl.xml | 109 - base_classes/NXelectronanalyser.nxdl.xml | 157 -- base_classes/NXem_correlation.nxdl.xml | 245 -- base_classes/NXem_ebsd.nxdl.xml | 1926 ---------------- base_classes/NXem_eels.nxdl.xml | 79 - base_classes/NXem_img.nxdl.xml | 63 - base_classes/NXem_method.nxdl.xml | 47 - base_classes/NXem_msr.nxdl.xml | 97 - base_classes/NXem_sim.nxdl.xml | 60 - base_classes/NXenergydispersion.nxdl.xml | 90 - base_classes/NXevent_data_apm.nxdl.xml | 281 --- base_classes/NXevent_data_apm_set.nxdl.xml | 48 - base_classes/NXevent_data_em.nxdl.xml | 226 -- base_classes/NXevent_data_em_set.nxdl.xml | 32 - base_classes/NXfabrication.nxdl.xml | 51 - base_classes/NXibeam_column.nxdl.xml | 144 -- base_classes/NXimage_set.nxdl.xml | 128 -- base_classes/NXinteraction_vol_em.nxdl.xml | 57 - base_classes/NXion.nxdl.xml | 168 -- base_classes/NXlens_em.nxdl.xml | 109 - base_classes/NXlens_opt.nxdl.xml | 185 -- base_classes/NXoptical_system_em.nxdl.xml | 83 - base_classes/NXpeak.nxdl.xml | 87 - base_classes/NXpid.nxdl.xml | 84 - base_classes/NXpulser_apm.nxdl.xml | 238 -- base_classes/NXpump.nxdl.xml | 43 - base_classes/NXreflectron.nxdl.xml | 86 - base_classes/NXroi.nxdl.xml | 34 - base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXspectrum_set.nxdl.xml | 162 -- base_classes/NXstage_lab.nxdl.xml | 173 -- base_classes/NXwaveplate.nxdl.xml | 173 -- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXapm_paraprobe_ranger_config.nxdl.xml | 240 -- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXapm_paraprobe_tool_config.nxdl.xml | 140 -- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 79 - .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcollectioncolumn.nxdl.xml | 104 + .../NXcomponent_em.nxdl.xml | 69 - contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 - contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- .../NXellipsometry.nxdl.xml | 357 +++ contributed_definitions/NXem_adf.nxdl.xml | 65 - .../NXem_conventions_ebsd.nxdl.xml | 230 -- .../NXem_ebsd_conventions.nxdl.xml | 610 +++++ .../NXgraph_node_set.nxdl.xml | 4 +- contributed_definitions/NXgraph_root.nxdl.xml | 4 +- .../NXimage_r_set_diff.nxdl.xml | 179 -- .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXisocontour.nxdl.xml | 4 +- .../NXmanipulator.nxdl.xml | 100 + .../NXmatch_filter.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 10 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ---- .../NXms_mtex_config.nxdl.xml | 310 --- contributed_definitions/NXms_odf.nxdl.xml | 171 -- contributed_definitions/NXms_odf_set.nxdl.xml | 33 - contributed_definitions/NXms_pf.nxdl.xml | 111 - contributed_definitions/NXms_pf_set.nxdl.xml | 33 - contributed_definitions/NXms_recon.nxdl.xml | 454 ---- .../NXms_score_results.nxdl.xml | 22 +- contributed_definitions/NXpulser_apm.nxdl.xml | 166 ++ contributed_definitions/NXreflectron.nxdl.xml | 56 + .../NXsimilarity_grouping.nxdl.xml | 97 +- .../NXspatial_filter.nxdl.xml | 4 +- .../NXspindispersion.nxdl.xml | 67 +- .../NXsubsampling_filter.nxdl.xml | 34 +- .../nyaml/NXcomponent_em.yaml | 39 - .../nyaml/NXcs_cpu_obj.yaml | 12 - .../nyaml/NXcs_cpu_sys.yaml | 21 - .../nyaml/NXcs_gpu_obj.yaml | 12 - .../nyaml/NXcs_gpu_sys.yaml | 20 - .../nyaml/NXcs_mm_obj.yaml | 21 - contributed_definitions/nyaml/NXem_adf.yaml | 28 - .../nyaml/NXem_conventions.yaml | 296 --- .../nyaml/NXem_conventions_ebsd.yaml | 125 - .../nyaml/NXimage_c_set.yaml | 140 -- .../nyaml/NXimage_r_set.yaml | 45 - .../nyaml/NXimage_r_set_diff.yaml | 123 - contributed_definitions/nyaml/NXms_ipf.yaml | 299 --- .../nyaml/NXms_ipf_set.yaml | 9 - .../nyaml/NXms_mtex_config.yaml | 187 -- contributed_definitions/nyaml/NXms_odf.yaml | 99 - .../nyaml/NXms_odf_set.yaml | 9 - contributed_definitions/nyaml/NXms_pf.yaml | 59 - .../nyaml/NXms_pf_set.yaml | 9 - contributed_definitions/nyaml/NXms_recon.yaml | 315 --- requirements.txt | 2 +- 126 files changed, 3318 insertions(+), 16504 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 applications/NXmpes.nxdl.xml delete mode 100644 base_classes/NXaberration.nxdl.xml delete mode 100644 base_classes/NXapm_charge_state_analysis.nxdl.xml delete mode 100644 base_classes/NXapm_hit_finding.nxdl.xml delete mode 100644 base_classes/NXapm_msr.nxdl.xml delete mode 100644 base_classes/NXapm_ranging.nxdl.xml delete mode 100644 base_classes/NXapm_reconstruction.nxdl.xml delete mode 100644 base_classes/NXapm_volt_and_bowl.nxdl.xml delete mode 100644 base_classes/NXcalibration.nxdl.xml delete mode 100644 base_classes/NXchamber.nxdl.xml delete mode 100644 base_classes/NXchemical_composition.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcrystal_structure.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 base_classes/NXcs_prng.nxdl.xml delete mode 100644 base_classes/NXcs_profiling.nxdl.xml delete mode 100644 base_classes/NXcs_profiling_event.nxdl.xml delete mode 100644 base_classes/NXdistortion.nxdl.xml delete mode 100644 base_classes/NXebeam_column.nxdl.xml delete mode 100644 base_classes/NXelectronanalyser.nxdl.xml delete mode 100644 base_classes/NXem_correlation.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXem_eels.nxdl.xml delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_method.nxdl.xml delete mode 100644 base_classes/NXem_msr.nxdl.xml delete mode 100644 base_classes/NXem_sim.nxdl.xml delete mode 100644 base_classes/NXenergydispersion.nxdl.xml delete mode 100644 base_classes/NXevent_data_apm.nxdl.xml delete mode 100644 base_classes/NXevent_data_apm_set.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXevent_data_em_set.nxdl.xml delete mode 100644 base_classes/NXfabrication.nxdl.xml delete mode 100644 base_classes/NXibeam_column.nxdl.xml delete mode 100644 base_classes/NXimage_set.nxdl.xml delete mode 100644 base_classes/NXinteraction_vol_em.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXlens_opt.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpeak.nxdl.xml delete mode 100644 base_classes/NXpid.nxdl.xml delete mode 100644 base_classes/NXpulser_apm.nxdl.xml delete mode 100644 base_classes/NXpump.nxdl.xml delete mode 100644 base_classes/NXreflectron.nxdl.xml delete mode 100644 base_classes/NXroi.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml delete mode 100644 base_classes/NXwaveplate.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcollectioncolumn.nxdl.xml delete mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml delete mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXellipsometry.nxdl.xml delete mode 100644 contributed_definitions/NXem_adf.nxdl.xml delete mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd_conventions.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXmanipulator.nxdl.xml delete mode 100644 contributed_definitions/NXms_ipf.nxdl.xml delete mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf.nxdl.xml delete mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf.nxdl.xml delete mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_recon.nxdl.xml create mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml create mode 100644 contributed_definitions/NXreflectron.nxdl.xml rename base_classes/NXdeflector.nxdl.xml => contributed_definitions/NXspindispersion.nxdl.xml (57%) delete mode 100644 contributed_definitions/nyaml/NXcomponent_em.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_mm_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXem_adf.yaml delete mode 100644 contributed_definitions/nyaml/NXem_conventions.yaml delete mode 100644 contributed_definitions/nyaml/NXem_conventions_ebsd.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_c_set.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_r_set.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_r_set_diff.yaml delete mode 100644 contributed_definitions/nyaml/NXms_ipf.yaml delete mode 100644 contributed_definitions/nyaml/NXms_ipf_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_mtex_config.yaml delete mode 100644 contributed_definitions/nyaml/NXms_odf.yaml delete mode 100644 contributed_definitions/nyaml/NXms_odf_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_pf.yaml delete mode 100644 contributed_definitions/nyaml/NXms_pf_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_recon.yaml diff --git a/Makefile b/Makefile index 634d75e0e..3a882c256 100644 --- a/Makefile +++ b/Makefile @@ -72,8 +72,6 @@ pdf :: $(SPHINX) -M latexpdf $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build cp $(BUILD_DIR)/manual/build/latex/nexus.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf -# for development purposes switch off the -W flag in the following line to make testing the local -# building of the manual more efficient html :: $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 6f02ae180..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - 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 available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - 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 specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - 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. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 0509b9086..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,2036 +0,0 @@ - - - - - - - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of a comprehensive data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process and maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **A comprehensive schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and vocabulary, with implementation in many data and file formats, - difficult to make interoperable. Instead of trying to maintain this, we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. - - **Verification of constraints and conditions**: - Tools like NeXus do not avoid or protect against all such possible inconsistencies; - however NeXus offers a mechanism and toolset, through which schemas can be - documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have their own em_lab section. - The reason is that EMs can be highly dynamic, used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store an arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details of who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, this is a place for documenting available - default plottable data. A default plottable can be useful for research data - management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables are not intended to serve every possible analysis and - visualization demand but are instead a preview. We made this choice - because what constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables the - display of image and spectra with web technology visualization software. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ - fields which support additional plotting of the data with visualization software. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images based on electron counts are typically detected with specific operation modes - such as bright field or dark field imaging in TEM or secondary/back-scattered electron - imaging in SEM. - * Also spectra (X-ray quanta or Auger electron counts) typically are referred to - under the assumption of a specific operation mode of the microscope. - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. - - The application definition NXem is a graph which describes how numerical data - and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2..000000000 --- a/applications/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/base_classes/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml deleted file mode 100644 index edfc74450..000000000 --- a/base_classes/NXaberration.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Quantified aberration coefficient in an aberration_model. - - - - - Confidence - - - - - How was the uncertainty quantified e.g. via the 95% confidence interval. - - - - - 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. - - - - - diff --git a/base_classes/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml deleted file mode 100644 index 3b6191151..000000000 --- a/base_classes/NXapm_charge_state_analysis.nxdl.xml +++ /dev/null @@ -1,157 +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). - - - - - Base class to document an algorithm for recovering charge state and nuclid 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 the nuclids 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 proton numbers for each element of the ranging - definition. The list contains each element as many times as its multiplicity. - As an example a ranging definition H:2 O:1 demands element vector - to be 1, 1, 8. An empty list does not release the constraint. - Instead, a list with all elements in the periodic table should be - used. Keep in mind though with such 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 nuclid of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - - - - - Input constraint, minimum natural abundance of each nuclid 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 - nuclids but the charge_state of all the ions is the same. - - - - - - Signed charge, i.e. integer multiple of the elementary charge. - - - - - - - - List of nuclids building each candidate. - Each list is sorted in descending order. - Unused values up to n_ivec_max are nullified. - - - - - - - - - Accumulated mass of the nuclids in each candidate. - Not corrected for quantum effects. - - - - - - - - The product of the natural abundances of the nuclids for each candidate. - - - - - - - - For each candidate the half life of the nuclid with the shortest half life. - - - - - - diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml deleted file mode 100644 index e05baf1ea..000000000 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of delay-line wires of the detector. - - - - - Number of hit qualities (hit types) distinguished. - - - - - 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 an application - definition is used to store results of already reconstructed datasets. - - - - - Base class for the configuration and results from a hit finding algorithm. - - - - - - - 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. - - - - - - - - - - - Evaluated ion impact coordinates on the detector. - Use the depends_on field to spec - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` in which the positions - are defined. - - - - - - Name of the hit_qualities distinguished. - AMETEK/Cameca uses e.g. golden, multiple, partial, - irrecoverable, and multi-first and multi-late. - - - - - - - - Identifier used for each hit_quality type. - Following the order of hit_quality_types. - - - - - Hit quality identifier for each pulse. - Identifier have to be within hit_quality_identifier. - - - - - - - - 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 (which is instead encoded with the - isotope_vector field of each :ref:`NXion` instance). - - - - - - - diff --git a/base_classes/NXapm_msr.nxdl.xml b/base_classes/NXapm_msr.nxdl.xml deleted file mode 100644 index 948d69b0e..000000000 --- a/base_classes/NXapm_msr.nxdl.xml +++ /dev/null @@ -1,176 +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 - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for collecting a session with a real atom probe or field-ion microscope. - - Ideally, we would like to describe the workflow of experiments and simulations of atom probe and - field-evaporation simulation research in more detail and contextualize better descriptions of - experiments and computer simulations for atom probe research. - - The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). - To arrive at a design of base classes and an application definition which 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 - wortwhile 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 are can be considered - as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling - i.e. algorithms for defining 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. 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 hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit - time and course of the experiment given that ion extraction is a sequential physical 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>`_ , or `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. - - By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the - whereabouts of each ion evaporated if needed. 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 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 its reconstructions. 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 addition 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 are simplified - because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. - Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path - instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - - To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become - obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a - real atom probe if considering that the simulation is just stripped of many components. - - - - Metadata of the atom probe or field-ion microscope instrument, henceforth called - microscope or instrument, and the lab in which it stands. - - - - Possibility to include a detailed computational geometry description of the - instrument. - - - - - Given name of the microscope as defined by the hosting lab. This is an alias. - Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - A counter electrode of the LEAP 6000 series atom probes. - - - - - - A local electrode guiding the ion flight path. - Also called counter or extraction electrode. - - - - - - Detector for taking raw time-of-flight and ion/hit impact positions data. - - - - - - - - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml deleted file mode 100644 index ab3a8afaf..000000000 --- a/base_classes/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>`_ - - - - - - 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>`_). - - - - - 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. - - - - - diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml deleted file mode 100644 index 03f5ff709..000000000 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ /dev/null @@ -1,123 +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 - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! - - - - - 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). - - - - - 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 parameterizing 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/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml deleted file mode 100644 index f317e76cb..000000000 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ /dev/null @@ -1,69 +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 - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! - - - - - Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. - - The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position - flight path differences, detector biases, and nonlinearities. - - - - - - - Raw time-of-flight data without corrections. - - - - - - - - Calibrated time-of-flight. - - - - - - diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml deleted file mode 100644 index 6d5a7ee58..000000000 --- a/base_classes/NXcalibration.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/base_classes/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml deleted file mode 100644 index edf318e2a..000000000 --- a/base_classes/NXchamber.nxdl.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - - - - Component of an instrument to store or place objects and specimens. - - - - Given name/alias. - - - - - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. - - - - diff --git a/base_classes/NXchemical_composition.nxdl.xml b/base_classes/NXchemical_composition.nxdl.xml deleted file mode 100644 index 0625ccf28..000000000 --- a/base_classes/NXchemical_composition.nxdl.xml +++ /dev/null @@ -1,69 +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. - - - - - Total based on which composition information is normalized. - - - - - - - - - Count or weight which, when divided by total yields the composition - of this element, isotope, molecule or ion. - - - - - - - - Count divided by total in atom percent. - - - - - - - diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956..000000000 --- a/base_classes/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second 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. - - - - - - diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index eca8ef217..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index fcca05d7a..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau aquisition. - - - - - The exposure time of the single tilt images. - - - - - The factor of enlargement of the apparent size, - not physical size, of an object. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - - - - - - - - - diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - 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. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index e6f1275ff..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a set of computing nodes. - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - A list of physical processing units (can be multi-core chips). - - - - - A list of physical coprocessor/graphic cards/accelerator units. - - - - - Details about the memory sub-system. - - - - - Details about the I/O sub-system. - - - diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index 2ee961538..000000000 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/base_classes/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml deleted file mode 100644 index 83d4e003a..000000000 --- a/base_classes/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - - diff --git a/base_classes/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml deleted file mode 100644 index d289ef292..000000000 --- a/base_classes/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 summary performance/profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - - - - - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - - - - - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - - diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 3b2d4be1d..000000000 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - - - - - Free-text description what was monitored/executed during the event. - - - - - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - Elapsed time may contain time portions where resources were idling. - - - - - Number of processes used (max) during the execution of this event. - - - - - Number of threads used (max) during the execution of this event. - - - - - Number of GPUs used (max) during the execution of this event. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/base_classes/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml deleted file mode 100644 index f1c5054e7..000000000 --- a/base_classes/NXdistortion.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of symmetry points used for distortion correction - - - - - Number of points of the matrix distortion field (x direction) - - - - - Number of points of the matrix distortion field (y direction) - - - - - Subclass of NXprocess to describe post-processing distortion correction. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the distortion correction been applied? - - - - - For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure expected - from the symmetry. Here we record the number of elementary symmetry operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - symmetry centre point. - - - - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - relevant symmetry points. - - - - - - - - - Column deformation field for general non-rigid distortion corrections. 2D matrix - holding the column information of the mapping of each original coordinate. - - - - - - - - - Row deformation field for general non-rigid distortion corrections. 2D matrix - holding the row information of the mapping of each original coordinate. - - - - - - - - - Description of the procedures employed. - - - diff --git a/base_classes/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml deleted file mode 100644 index e31f22fbc..000000000 --- a/base_classes/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195e..000000000 --- a/base_classes/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b51..000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - 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_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index aa3dd46be..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,1926 +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 orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - - - - - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - - - - - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - - - - - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - - - - - - - - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - - - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - - - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - - - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - - - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb6..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml deleted file mode 100644 index 79574ecaa..000000000 --- a/base_classes/NXem_img.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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? - - - - - - - - diff --git a/base_classes/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml deleted file mode 100644 index 0034919dd..000000000 --- a/base_classes/NXem_method.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. - - - - Details about processing steps. - - - - - - - diff --git a/base_classes/NXem_msr.nxdl.xml b/base_classes/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b8..000000000 --- a/base_classes/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - 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. - - - - - - - - - - - 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. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/base_classes/NXem_sim.nxdl.xml b/base_classes/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001..000000000 --- a/base_classes/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/base_classes/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bc..000000000 --- a/base_classes/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml deleted file mode 100644 index 878a5c3ff..000000000 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ /dev/null @@ -1,281 +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. - - 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 splitted 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_identifier 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 - (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_identifier, - 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_identifier 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_identifier the time difference - between when that pulse was issued and start_time. - - In summary, using start_time, end_time, delta_time, pulse_identifier_offset, - and pulse_identifier 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 - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_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 that contextualizes how the detector and pulser of an atom probe - instrument follows a sequence of pulses to trigger field evaporation. - - The pulse_identifier is used to associate thus an information about time - when the quantities documented in this NXpulser_apm base class 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_identifier 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_identifier 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_identifier are then [0, 99999] respectively. - - - - - - - - (Meta)data of the dynamics and changes of the microscope over the course of - pulsing. - - - - Relevant quantities during a measurement with a LEAP system as suggested by - `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. - - - - - - - - - - - - - - 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. - - - - - - - - - - - - Set point temperature to achieve during the measurement. - - - - - Average temperature (at the specimen base) during the measurement. - - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Average pressure in the analysis chamber during the measurement. - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - diff --git a/base_classes/NXevent_data_apm_set.nxdl.xml b/base_classes/NXevent_data_apm_set.nxdl.xml deleted file mode 100644 index 96670759b..000000000 --- a/base_classes/NXevent_data_apm_set.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - Base class for a set of :ref:`NXevent_data_apm` instances. - - Members of the set are instances of :ref:`NXevent_data_apm`. - These have an associated time interval during which the conditions - of the instrument were considered stable and fit enough for purpose. - - 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 evaporated_identifier but as a - function of the (pulsing) event_identifier. - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index f32978259..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope. - - - - - 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. - - - - - - - - - diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index e5f40c95a..000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. - - - diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml deleted file mode 100644 index 1f940f079..000000000 --- a/base_classes/NXfabrication.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - - diff --git a/base_classes/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml deleted file mode 100644 index eea601c4e..000000000 --- a/base_classes/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - - Average/nominal brightness - - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - - diff --git a/base_classes/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml deleted file mode 100644 index a482480c8..000000000 --- a/base_classes/NXimage_set.nxdl.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Container for reporting a set of images taken. - - - - Details how images were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center of mass along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center of mass along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/base_classes/NXinteraction_vol_em.nxdl.xml b/base_classes/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index f8d8a669f..000000000 --- a/base_classes/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - Base class for describing the interaction volume 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 are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 99a19f2e3..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index 925aa35aa..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For NXtransformations the origin of the coordinate system is placed - in the center of the lens - (its polepiece, pinhole, or another point of reference). - The origin should be specified in the NXtransformations. - - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/base_classes/NXlens_opt.nxdl.xml b/base_classes/NXlens_opt.nxdl.xml deleted file mode 100644 index 753a58e55..000000000 --- a/base_classes/NXlens_opt.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.). - - - - - - - - - - - - - - - If you chose 'other' as type specify what it is. - - - - - Is it a chromatic lens? - - - - - Diameter of the lens. - - - - - Properties of the substrate material of the lens. If the lens has a - coating specify the coating material and its properties in 'coating'. - - - - Specify the substrate material of the lens. - - - - - Thickness of the lens substrate at the optical axis. - - - - - Complex index of refraction of the lens material. Specify at given - wavelength (or energy, wavenumber etc.) values. - - - - - - - - - - - If the lens has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the lens are coated with different - materials, use separate COATING(NXsample) fields to describe the coatings - on the front and back side, respectively. For example: - coating_front(NXsample) and coating_back(NXsample). - - - - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - - - - - Describe the coating material (e.g. MgF2). - - - - - Thickness of the coating. - - - - - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - - - - - - - - - - Reflectance of the lens at given spectral values. - - - - - - - - Transmission of the lens at given spectral values. - - - - - - - - Focal length of the lens on the front side (first value), i.e. where the - beam is incident, and on the back side (second value). - - - - - - - - Curvature radius of the lens. - Instead of 'FACE' in the name of this field, the user is advised to - specify for which surface (e.g. front or back) the curvature is provided: - e.g. curvature_front or curvature_back. The front face is the surface on - which the light beam is incident, while the back face is the one from - which the light beam exits the lens. - - - - - Abbe number (or V-number) of the lens. - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index 0f753001e..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - - diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml deleted file mode 100644 index 4a030c684..000000000 --- a/base_classes/NXpeak.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/base_classes/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml deleted file mode 100644 index 62fad3f83..000000000 --- a/base_classes/NXpid.nxdl.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - Contains the settings of a PID controller. - - - - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - - - - - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - - - - - The actual timeseries data fed back to the PID loop. - - - - - - - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - - - - - Proportional term. The proportional term produces an output value - that is proportional to the current error value. - The proportional response can be adjusted by multiplying the error - by a constant Kp, called the proportional gain constant. - - - - - The contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - - - - - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - - - diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml deleted file mode 100644 index 3a856635b..000000000 --- a/base_classes/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,238 +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 - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for a laser- and/or voltage-pulsing device used in atom probe - microscopy. - - - - - Detail whereby ion extraction is triggered methodologically. - - - - - - - - - - - Frequency with which the pulser fire(s). - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - 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_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - Pulsed voltage, in laser pulsing mode this field can be omitted. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Absolute number of pulses starting from the beginning of the experiment. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - 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_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - 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. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - Average energy of the laser at peak of each pulse. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - 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_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Track time-dependent settings over the course of the measurement - where the laser beam exits the focusing optics. - - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - - - Path to pulse_identifier 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. - - - - - diff --git a/base_classes/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml deleted file mode 100644 index 98e6e02b2..000000000 --- a/base_classes/NXpump.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - - diff --git a/base_classes/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml deleted file mode 100644 index f982a6e61..000000000 --- a/base_classes/NXreflectron.nxdl.xml +++ /dev/null @@ -1,86 +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 - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for a 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 - - - - Status of eventual existence and potential usage of this reflectron. - - - - - - - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - The maximum voltage applied to the reflectron, relative to system ground. - - - - - - Affine transformation(s) which detail where the reflectron is located - relative to e.g. the origin of the specimen space reference coordinate - system. This group can also be used for specifying how the reflectron - is rotated relative to a given axis in the instrument. - - - - diff --git a/base_classes/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml deleted file mode 100644 index 94857e74c..000000000 --- a/base_classes/NXroi.nxdl.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - Base class to describe a region-of-interest analyzed. - - - - Details about processing steps. - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index c95f62357..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - - - - diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 9ca3aab34..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - Number of pixel in the slow direction. - - - - - Number of pixel in the fast direction. - - - - - Number of energy bins. - - - - - Container for reporting a set of spectra. - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - - - - - Link or name of an NXdetector instance with which the data were collected. - - - - - - - - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - Counts - - - - - - - - - - - Coordinate along y direction - - - - - - - - - - Coordinate along x direction - - - - - - - - - - Energy - - - - - - - - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - Counts - - - - - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 7b916d272..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - A stage lab can be used to hold, align, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. - - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. - - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. - - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. - - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Given name/alias for the components making the stage. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - Should be defined by the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - - - - diff --git a/base_classes/NXwaveplate.nxdl.xml b/base_classes/NXwaveplate.nxdl.xml deleted file mode 100644 index 52abcb0ba..000000000 --- a/base_classes/NXwaveplate.nxdl.xml +++ /dev/null @@ -1,173 +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 waveplate or zero-order waveplate). - - - - - - - - - - - - - - If you selected 'other' in type describe what it is. - - - - - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4) plate). - - - - - - - - - - Discrete wavelengths for which the waveplate is designed. If the - waveplate operates over an entire range of wavelengths, enter the minimum - and maximum values of the wavelength range (in this case - N_wavelengths = 2). - - - - - - - - Diameter of the waveplate. - - - - - Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of - length/height for square geometry). - - - - - - Describe the material of the substrate of the wave plate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - - - - Specify the material of the wave plate. If the device has a - coating it should be described in coating/coating_material. - - - - - Thickness of the wave plate substrate. - - - - - Complex index of refraction of the wave plate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. - - - - - - - - - - Is the wave plate coated? If yes, specify the type and material of the - coating and the wavelength range for which it is designed. If known, you - may also provide its index of refraction. - - - - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - - - - - Specify the coating material. - - - - - Thickness of the coating. - - - - - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. - - - - - - - - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - - - - - - - - - - Average reflectance of the waveplate in percentage. - - - diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index db06948bd..c340fc2ae 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of isotopes to consider as building blocks for searching molecular - ions. - - - - - The number of compositions to consider for molecular ion search tasks. - - - - - 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. - - - - - Version specifier of this application definition. - - - - - NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 2b52cb521..aae16541e 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -2,9 +2,9 @@ - - - - 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). - - - - - - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - - - - - 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. - - - - - - Metadata of the computational process whereby this configuration was generated. - There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create HDF5 configuration files, i.e. instances. - - - - 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 creation of the configuration 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 creation of the configuration was - completed and the respective process of the tool exited. - - - - - - 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. - 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 to use for this analysis. - - - - - - 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. - - - - Name of the (parent) node directly below which (in the hierarchy) - the ranging definition for (molecular) ions are stored. - - - - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml deleted file mode 100644 index c2b2891af..000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Application definition for a configuration file of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - Version specifier of this application definition. - - - - - NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 000000000..38a448a0e --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 000000000..ea8faee3e --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 000000000..96c2d7123 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 000000000..ca4a56984 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 000000000..e5c351839 --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 000000000..e90dd652f --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 000000000..e3a6e99fe --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 000000000..e50192cf8 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 000000000..b3e27b0f9 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 000000000..3640f8ff3 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml new file mode 100644 index 000000000..5348d55b5 --- /dev/null +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml deleted file mode 100644 index a68436e9b..000000000 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. - - - - Given name to the component e.g stage, lens C1, etc. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml deleted file mode 100644 index e7fedabd4..000000000 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of coprocessor or graphics processors. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d..eb1e7e19c 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + + + + + Number of time points measured, the length of NXsample/time_points + + + + + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + + + + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + + + An application definition for ellipsometry. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + + + + + Specify the type of ellipsometry. + + + + + + + + + + + + + + Properties of the ellipsometry equipment. + + + + Name of the company which build the instrument. + + + + + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. + + + + + + What type of ellipsometry was used? See Fujiwara Table 4.2. + + + + + + + + + + + + + + + + + + + Define which element rotates, e.g. polarizer or analyzer. + + + + + + + + + + + + Specify the used light source. Multiple selection possible. + + + + + + + + + + + + + If focussing 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 + focussing probes (lenses)? + + + + + Specify the angular spread caused by the focussing probes. + + + + + + Properties of the detector used. Integration time is the count time + field, or the real time field. See their definition. + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + + + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + + + + + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + + + + + Specify the maximum value of revolutions of the rotating element + for each measurement. + + + + + + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range can + be stored in grating_dispersion. + + + + + + + + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + + + + + + + Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_observables) are + stored in the data array. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml deleted file mode 100644 index 110642413..000000000 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Base class method-specific for annular dark field imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. - - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - - diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml deleted file mode 100644 index d2d7456aa..000000000 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml new file mode 100644 index 000000000..7ef85f871 --- /dev/null +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -0,0 +1,610 @@ + + + + + + + Conventions for rotations and coordinate systems to interpret EBSD data. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, e.g. rolling direction. + + + + + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the y-axis base vector, e.g. transverse direction. + + + + + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the z-axis base vector, e.g. normal direction. + + + + + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the sample/specimen reference frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the detector reference frame. + + + + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index fb0429164..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -2,9 +2,9 @@ - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 000000000..a6beeb648 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index d42b1ab9e..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ + + + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. + + + + Name of the manipulator. + + + + + A description of the manipulator. + + + + + Type of manipulator, Hexapod, Rod, etc. + + + + + Is cryocoolant flowing through the manipulator? + + + + + Temperature of the cryostat (coldest point) + + + + + Power in the heater for temperature control. + + + + + Temperature at the closest point to the sample. This field may also be found in + NXsample if present. + + + + + Current to neutralize the photoemission current. This field may also be found in + NXsample if present. + + + + + Possible bias of the sample with trespect to analyser ground. This field may + also be found in NXsample if present. + + + + + Class to describe the motors that are used in the manipulator + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the manipulator as a component in the instrument. Conventions from + the NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index b7fcbbabf..482b028d9 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -2,9 +2,9 @@ +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml deleted file mode 100644 index 0be3dc81e..000000000 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - - - - Number of pixel along the z slowest direction. - - - - - Number of pixel along the y slow direction. - - - - - Number of pixel along the x fast direction. - - - - - Number of RGB values along the fastest direction, always three. - - - - - Dimensionality of the mapping (either 2 or 3). - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - - - - - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel center coordinate calibrated for step size along the z axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the y axis of the map. - - - - - - - - - Pixel center coordinate calibrated for step size along the x axis of the map. - - - - - - - - - - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the 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. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml deleted file mode 100644 index 90e4132be..000000000 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - - - - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - TODO with MTex developers - - - - - - - - - - - Settings relevant for generating plots. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - True if MTex renders a scale bar with figures. - - - - - True if MTex renders a grid with figures. - - - - - Code for the function handle used for annotating pole figure plots. - - - - - TODO with MTex developers - - - - - - - - - TODO with MTex developers - - - - - - - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous other settings of MTex. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - - Miscellaneous settings relevant for numerics. - - - - Return value of the Matlab eps command. - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Miscellaneous settings relevant of the system where MTex runs. - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - TODO with MTex developers - - - - - - Collection of paths from where MTex reads information and code. - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - Absolute path to specific component of MTex source code. - - - - - List of file type suffixes for which MTex assumes - texture/pole figure information. - - - - - List of file type suffixes for which MTex assumes EBSD content. - - - - - diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml deleted file mode 100644 index 3e9d11dd7..000000000 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the varphi_one fastest direction. - - - - - Number of pixel per varphi section plot along the capital_phi slow direction. - - - - - Number of pixel per varphi section plot along the varphi_two slowest direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Base class to store an orientation distribution function (ODF) computation. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - - - - - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Number of local maxima evaluated for the ODF. - - - - - - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - - - - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - - - - - - - - - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - - - - - ODF intensity at probed locations relative to - null model of a completely random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml deleted file mode 100644 index c21aa3698..000000000 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_odf` instances. - - A collection of orientation distribution function approximations. - - - diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml deleted file mode 100644 index 44db61d7b..000000000 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - - 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. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - - - - - Point group assumed for processing induced *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/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml deleted file mode 100644 index 14a4061d6..000000000 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. - - - diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml deleted file mode 100644 index f44d34239..000000000 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of crystal projections. - - - - - The number of interface projections. - - - - - The number of assumed triple junction projections aka triple points. - - - - - - The number of crystals. - - - - - The number of interfaces - - - - - The number of triple lines - - - - - The number of quadruple junctions. - - - - - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. - - - - - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - - - - - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - - - - - - - - - - Which algorithm is used to reconstruct the features. - - - - - - - - - - - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - - - - - - - - - - - - - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - - - - - Number of crystals. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier used for crystals for explicit indexing. - - - - - - - - How many phases are distinguished - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - - - - - Identifier used for phase for explicit indexing. - - - - - - - - - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - - - - - - - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - - - - - - - - - Calibrated area of surrounded by the polyline about each crystal. - - - - - - - - - - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - - - - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - - - - - - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - - - - - - - - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - - - - - - - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - - - - - - - - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - - - - - - - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each interface using explicit indexing. - - - - - - - - - - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - - - - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - - - - - - Number of triple points. - - - - - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - - - - - Identifier for each triple point using explicit indexing. - - - - - - - - Set of triple point identifiers. - - - - - - - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - - - - - - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - - - - - - - - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - - - - - - - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - - - - - - - - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 77c73b42f..0e957612e 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -693,27 +691,21 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml new file mode 100644 index 000000000..a57b1af0d --- /dev/null +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -0,0 +1,166 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + 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. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 000000000..e2220a1be --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e28..2973b9d64 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,26 +43,29 @@ - Total number of similarity groups aka features/clusters. + Total number of similarity groups aka features, objects, clusters. - Base class to store results obtained from applying a similarity grouping (clustering) algorithm. + Metadata to the results of a similarity grouping analysis. - 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. + Similarity grouping analyses can be supervised segmentation or machine learning + clustering algorithms. These are routine methods which partition the member of + a set of objects/geometric primitives into (sub-)groups, features of + different type. A plethora of algorithms have been proposed which can be applied + also on geometric primitives like points, triangles, or (abstract) features aka + objects (including categorical sub-groups). - This base class considers metadata and results of 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. + This base class considers metadata and results of one similarity grouping + analysis applied to a set in which objects are either categorized as noise + or belonging to a cluster. + As the results of the analysis each similarity group, here called feature + aka object can get a number of numerical and/or categorical labels. - Number of members in the set which gets partitioned into features. + Number of members in the set which is partitioned into features. @@ -75,25 +78,26 @@ How many categorical labels does each feature have. - - + + - Which numerical identifier is the first to be used to label a feature. + 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 that an object belongs to no cluster. - * identifier_offset - 2 indicates that an object belongs to the noise category. + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned - points to 0. Numerical identifier have to be strictly increasing. + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + + - + Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance @@ -108,6 +112,8 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. + @@ -115,39 +121,44 @@ results for the object set--> - In addition to the detailed storage which objects were grouped to which + In addition to the detailed storage which members was grouped to which feature/group summary statistics are stored under this group. - - + + - Total number of features categorized as unassigned. + Total number of members in the set which are categorized as unassigned. + + + - Total number of features categorized as noise. + Total number of members in the set which are categorized as noise. + + + - + + - Total number of features. + Total number of clusters (excluding noise and unassigned). - - + - Array of numerical identifier of each feature. + Array of numerical identifier of each feature (cluster). - + + - + - Array of number of objects for each feature. + Array of number of members for each feature. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 89c04950e..25e5ae820 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -2,9 +2,9 @@ - + - Deflectors as they are used e.g. in an electron analyser. + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. - + + + Type of spin detector, VLEED, SPLEED, Mott, etc. + + + - Qualitative type of deflector with respect to the number of pole pieces + Figure of merit of the spin detector - - - - - - - + - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. + Effective Shermann function, calibrated spin selectivity factor - + - Name of the manufacturer who built/constructed the deflector. + Energy of the spin-selective scattering - + - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. + Angle of the spin-selective scattering - + - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. + Name of the target - + - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Preparation procedure of the spin target - + - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Date of last preparation of the spin target - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. @@ -89,4 +84,14 @@ the reference coordinate system. + + + Deflectors in the spin dispersive section + + + + + Individual lenses in the spin dispersive section + + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0310e9f26..ea378eab3 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Base class of a filter to sample members in a set based on their identifier. + Settings of a filter to sample entries based on their value. - + - Triplet of the minimum, the increment, and the maximum identifier to - include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` - of identifier. The increment controls which n-th identifier (value) to take. + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. - Take as an example a dataset with 100 identifier (aka entries). Assume that - the identifier start at zero, i.e. identifier_offset is 0). Assume further - that min_incr_max is set to [0, 1, 99]. In this case the filter will - yield all identifier. Setting min_incr_max to [0, 2, 99] will take each - second identifier. Setting min_incr_max to [90, 3, 99] will take each - third identifier beginning from identifier 90 up to 99. + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml deleted file mode 100644 index 78870cc26..000000000 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. -# `point Electronic GmbH `_ -type: group -NXcomponent_em(NXobject): - name(NX_CHAR): - doc: | - Given name to the component e.g stage, lens C1, etc. - description(NX_CHAR): # NXidentifier - doc: | - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - (NXfabrication): - (NXprogram): - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. diff --git a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml deleted file mode 100644 index 73097d5ca..000000000 --- a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml +++ /dev/null @@ -1,12 +0,0 @@ -category: base -doc: | - Computer science description of a (central) processing unit (C)PU of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_cpu_obj(NXobject): - name(NX_CHAR): - doc: | - Given name of the CPU. Users should be as specific as possible. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml deleted file mode 100644 index 5eaf8f0ea..000000000 --- a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_cpu_sys(NXobject): - cpuID(NXcs_cpu_obj): - doc: | - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml deleted file mode 100644 index 04468b7b2..000000000 --- a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml +++ /dev/null @@ -1,12 +0,0 @@ -category: base -doc: | - Computer science description of a graphic processing unit (GPU) of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_gpu_obj(NXobject): # NXcircuit_board ? - name(NX_CHAR): - doc: | - Given name of the GPU. Users should be as specific as possible. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml deleted file mode 100644 index dee199330..000000000 --- a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml +++ /dev/null @@ -1,20 +0,0 @@ -category: base -doc: | - Computer science description of a system of coprocessor or graphics processors. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_gpu_sys(NXobject): - gpuID(NXcs_gpu_obj): - doc: | - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_mm_obj.yaml b/contributed_definitions/nyaml/NXcs_mm_obj.yaml deleted file mode 100644 index d1fead8c8..000000000 --- a/contributed_definitions/nyaml/NXcs_mm_obj.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Computer science description of a memory in a memory system. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_mm_obj(NXobject): - technology(NX_CHAR): - doc: | - Qualifier for the type of random access memory. - # make an enumeration - max_physical_capacity(NX_NUMBER): - doc: | - Total amount of data which the medium can hold. - unit: NX_ANY - # NX_BIT - name(NX_CHAR): - doc: | - Given name to the I/O unit. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml deleted file mode 100644 index b7011639e..000000000 --- a/contributed_definitions/nyaml/NXem_adf.yaml +++ /dev/null @@ -1,28 +0,0 @@ -category: base -doc: | - Base class method-specific for annular dark field imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). 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. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_adf(NXem_method): - IMAGE_R_SET(NXimage_r_set): - half_angle_interval(NX_NUMBER): - doc: | - Annulus inner (first value) and outer (second value) half angle. - unit: NX_ANGLE - dim: (2,) - # all information about annular dark field images is composed from - # the NXimage_r_set_em base class diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml deleted file mode 100644 index 7835d9a65..000000000 --- a/contributed_definitions/nyaml/NXem_conventions.yaml +++ /dev/null @@ -1,296 +0,0 @@ -category: base -# symbols: -doc: | - Conventions for rotations and coordinate systems to interpret crystal orientation - and other data and results collected with electron microscopy research. - - Documenting explicitly all used conventions and coordinate systems is - the decisive context whereby many results from electron microscopy are - at all interpretable. - -# This base class provides several sets of such assumptions and conventions. -# Further base classes should be defined when specific techniques and methods -# demand further specifications or have specialized demands. NXem_conventions_ebsd -# is an example for such method-specific base class to summarize key conventions -# for Electron Backscatter Diffraction (EBSD). - -# What is could be a best practice for application definition developers -# who would like to describe an electron microscopy case where multiple -# methods and/or detectors are used. In this case one should define a -# method-specific base class like the template NXem_conventions_ebsd. -# Even though this may come at a cost of some duplicated information where -# the same physical detector is used in different ways, i.e. the signal collect -# from the detector is interpreted in a different way. -# As in most cases established types of signal and thus detectors are used -# (secondary electron, backscattered electron, etc.) one could equally use -# just one NXem_conventions base class instance in an application definition -# and use detector_reference_frame as a template. For each method and detector -# one then creates one NXprocess group named detector_reference_frame1, -# detector_reference_frame2, detector_reference_frame3, and so on and so forth -# and adds inside that NXprocess and use the depends_on field. - -# What is considered best practice in an application definition with multiple -# NXentry instances? In this case each NXentry instance should have an own -# NXspecimen instance and thus the NXem_conventions instance should be place -# inside that NXentry. This enables to group multiple experiments on multiple -# samples together without setting a constraint that in all these instances -# the conventions have to be the same. - -# However, best practice is the conventions should be expressed explicitly -# and they should whenever possible be as simple as possible and as few -# as possible to support users with understanding the content of the application -# definition. -type: group -NXem_conventions(NXobject): - # mandatory information about used or - # assumed reference frame and rotation conventions - rotation_conventions(NXobject): - doc: | - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. - 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, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - enumeration: [undefined, zxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, p_plus_one, p_minus_one] - processing_reference_frame(NXcoordinate_system): - doc: | - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - type(NX_CHAR): - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of coordinate system. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. rolling direction. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. transverse direction. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. normal direction. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - sample_reference_frame(NXcoordinate_system): - doc: | - Details about the sample/specimen reference frame. - type(NX_CHAR): - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. long edge. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. shortest edge. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - detector_reference_frameID(NXcoordinate_system): - doc: | - Details about the detector reference frame for a specific detector. - \@depends_on(NX_CHAR): - doc: | - Reference to the specifically named :ref:`NXdetector` instance - for which these conventions in this :ref:`NXprocess` group apply - (e.g. /entry1/instrument/detector1). - type(NX_CHAR): - doc: | - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge as some landmark on the detector. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. long edge as some landmark on the detector. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. short edge as some landmark on the detector. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - # conventions specific for EBSD - (NXem_conventions_ebsd): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml b/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml deleted file mode 100644 index 1ec180e23..000000000 --- a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml +++ /dev/null @@ -1,125 +0,0 @@ -category: base -# symbols: -doc: | - Base class for method-specific conventions EBSD. - - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. -type: group -NXem_conventions_ebsd(NXem_conventions): - gnomonic_projection_reference_frame(NXcoordinate_system): - doc: | - Details about the gnomonic projection reference frame. - type(NX_CHAR): - doc: | - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of coordinate system. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, in_the_pattern_centre] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - pattern_centre(NXprocess): - doc: | - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - 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? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - enumeration: [undefined, top, right, bottom, left] - x_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - enumeration: [undefined, north, east, south, west] - 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? - For further details inspect the help button of - xaxis_boundary_convention. - enumeration: [undefined, top, right, bottom, left] - y_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - enumeration: [undefined, north, east, south, west] - - # distance_convention: - # doc: | - # How is the third of the three pattern centre parameter values, - # the (distance) parameter DD, normalized. Which convention - # is followed. We are aware that specifying one of the options here - # also implicitly comes with conventions for some of the parameter - # requested in this ELN. For now we would rather like to ask - # the users though to be specific also to learn how such an ELN - # will be used in practice. - # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXimage_c_set.yaml b/contributed_definitions/nyaml/NXimage_c_set.yaml deleted file mode 100644 index 8dcd85706..000000000 --- a/contributed_definitions/nyaml/NXimage_c_set.yaml +++ /dev/null @@ -1,140 +0,0 @@ -category: base -doc: | - Specialized base class container for reporting a set of 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 - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `FFTW by M. Frigo and S. G. Johnson `_ - * `Intel MKL by the Intel Co. `_ - * `cuFFT by the NVidia Co. `_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. -symbols: - n_images: | - Number of images in the (hyper)stack. - n_k: | - Number of pixel per image in the slowest direction. - n_j: | - Number of pixel per image in the slow direction. - n_i: | - Number of pixel per image in the fast direction. -type: group -NXimage_c_set(NXimage_set): - # details about the FFT library used could for instance be stored in the - # NXprocess group which the NXimage_c_set base class can borrow from its - # NXimage_set parent base class - # process information are composable from the NXimage_set base class - stack(NXdata): - doc: | - Image stack. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - # axis_k(NX_NUMBER): - # doc: | - # Pixel coordinate center along k direction. - # unit: NX_ANY # NX_RECIPROCAL_LENGTH - # dim: (n_k,) - # \@long_name(NX_CHAR): - # doc: | - # Coordinate along j direction. - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - hyperstack(NXdata): - doc: | - Image hyperstack. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_k(NX_NUMBER): - doc: | - Pixel coordinate center along k direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set.yaml b/contributed_definitions/nyaml/NXimage_r_set.yaml deleted file mode 100644 index f0437e6e6..000000000 --- a/contributed_definitions/nyaml/NXimage_r_set.yaml +++ /dev/null @@ -1,45 +0,0 @@ -category: base -doc: | - Specialized base class container for reporting a set of images in real space. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXimage_r_set(NXimage_set): - # process information are composable from the NXimage_set base class - stack(NXdata): - doc: | - Image (stack). - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_images, n_y, n_x) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_y(NX_NUMBER): - doc: | - Pixel coordinate center along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml deleted file mode 100644 index 79ca31b16..000000000 --- a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml +++ /dev/null @@ -1,123 +0,0 @@ -category: base -doc: | - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and related :ref:`NXem_base` classes extend the - work of `M. A. Jackson et al. `_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. `_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. -symbols: - n_sc: | - Number of scanned points. Scan point may have none, one, or more pattern. - n_p: | - Number of diffraction pattern. - n_y: | - Number of pixel per pattern in the slow direction. - n_x: | - Number of pixel per pattern in the fast direction. -type: group -NXimage_r_set_diff(NXimage_r_set): - pattern_type(NX_CHAR): - doc: | - Category which type of diffraction pattern is reported. - enumeration: [kikuchi] - stack(NXdata): - doc: | - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - scan_point_identifier(NX_INT): - doc: | - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - unit: NX_UNITLESS - dim: (n_p,) - intensity(NX_NUMBER): - doc: | - Intensity of the diffraction pattern. - unit: NX_UNITLESS - dim: (n_p, n_y, n_x) - # n_p fast 2, n_y faster 1, n_x fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name(NX_CHAR): - doc: | - Pattern intensity - # \@signal: intensity - # \@axes: [pattern_identifier, ypos, xpos] - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@pattern_identifier_indices: 2 - pattern_identifier(NX_INT): - doc: | - Pattern are enumerated starting from 0 to n_p - 1. - unit: NX_UNITLESS - dim: (n_p,) - \@long_name(NX_CHAR): - doc: | - Pattern identifier - # the following fields are taken from the NXimage_r_set base class - # axis_y(R): - # axis_x(R): - -# If we envision a (knowledge) graph for EBSD it consists of individual sub-graphs -# which convey information about the specimen preparation, the measurement of -# the specimen in the electron microscope, the indexing of the collected -# Kikuchi pattern stack, eventual post-processing of the indexed orientation -# images via similarity grouping algorithms to yield (grains, texture). -# Conceptually, these post-processing steps are most frequently serving -# the idea how can one reconstruct so-called microstructural features -# (grains, phases, interfaces) to infer material properties. -# In practice this calls for workflows which quantify correlations between -# the spatial arrangement of the microstructural features, the individual -# (thermodynamic, chemo-mechanical) properties of the features with the -# properties of materials at a coarser scale. -# With NXem and related NXms base classes we propose a covering -# and general solution how to handle such (meta)data with NeXus. diff --git a/contributed_definitions/nyaml/NXms_ipf.yaml b/contributed_definitions/nyaml/NXms_ipf.yaml deleted file mode 100644 index 11bfc5983..000000000 --- a/contributed_definitions/nyaml/NXms_ipf.yaml +++ /dev/null @@ -1,299 +0,0 @@ -category: base -doc: | - Base class to store an inverse pole figure (IPF) mapping (IPF map). -symbols: - # how to make this optional - n_z: | - Number of pixel along the z slowest direction. - n_y: | - Number of pixel along the y slow direction. - n_x: | - Number of pixel along the x fast direction. - n_rgb: | - Number of RGB values along the fastest direction, always three. - d: | - Dimensionality of the mapping (either 2 or 3). -type: group -NXms_ipf(NXprocess): - \@depends_on(NX_CHAR): - doc: | - Reference to the coordinate system whereby the projection_direction is defined. - - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. - - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. - projection_direction(NX_NUMBER): - doc: | - The direction along which orientations are projected. - unit: NX_UNITLESS - dim: (3,) - input_grid(NXcg_grid): - doc: | - Details about the original grid. - - Here original grid means the one onto which the IPF map was computed - when exported from the tech partner's file format representation. - output_grid(NXcg_grid): - doc: | - 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. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - interpolation(NX_CHAR): - doc: | - How where orientation values at the location of the output grid - positions computed. - - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. - enumeration: [nearest_neighbour] - map(NXdata): - doc: | - Inverse pole figure mapping. - - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier 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:`NXms_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools 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 - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. - # \@signal: data - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - data(NX_NUMBER): - # assume a mapping with step size 0.5 micron - # we need to distinguish - # pixel position, i.e. 0, 1, 2, 3, unit px - # answers in which pixel on the map but map is disconnected from sample surface context - # calibrated pixel position 0., 0.5, 1.0, 1.5, unit micron - # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context - # calibrated pixel position including the offset of the original coordinate system - # 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 - doc: | - Inverse pole figure color code for each map coordinate. - unit: NX_UNITLESS - dim: (n_y, n_x, 3) # | (n_z, n_y, n_x, 3) - axis_z(NX_NUMBER): - doc: | - Pixel center coordinate calibrated for step size along the z axis of the map. - unit: NX_LENGTH - dim: (n_z,) - # \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center coordinate calibrated for step size along the y axis of the map. - dim: (n_y,) - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center coordinate calibrated for step size along the x axis of the map. - dim: (n_x,) - # \@long_name(NX_CHAR): - # title: - legend(NXdata): - doc: | - The color code which maps colors into orientation into 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 each point in - the fundamental zone a color. - - 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) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. - # \@signal: data - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - data(NX_NUMBER): - # hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! - doc: | - Inverse pole figure color code for each map coordinate. - unit: NX_UNITLESS - dim: (n_y, n_x, 3) - axis_y(NX_NUMBER): - doc: | - Pixel along the y-axis. - unit: NX_UNITLESS - dim: (n_y,) - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - doc: | - Pixel along the x-axis. - unit: NX_UNITLESS - dim: (n_x,) - # \@long_name(NX_CHAR): - # title: - -# keep this for now for FAIRmat internal documentation -# It is important to mention that we cannot assume, at least for now, -# that the parser which writes to an NXem_ebsd-compliant file is also -# responsible or capable at all of computing the inverse pole figure -# color keys and maps itself. This cannot be assumed working because -# this mapping of orientation data uses involved mathematical algorithms -# and functions which not every tools used in the EBSD community is capable -# of using or is for sure not using in exactly the same way. -# -# Currently, we assume it is the responsibilty of the tool used which -# generated the data under on_the_fly_indexing to compute these -# plots and deliver these to the parser. -# -# Specific case studies have been explored by the experiment team of -# Area B of the FAIRmat project to realize and implement such mapping. -# -# The first case study uses the H5OINA format and the pyxem/orix library. -# As orix is a Python library, the coloring is performed by the em_om parser. -# -# The second case study uses MTex and its EBSD color coding model. -# As MTex is a Matlab tool, an intermediate format is written from MTex -# first which stores these pieces of information. The parser then pulls -# these data from the intermediate Matlab-agnostic representation and -# supplements the file with missing pieces of information as it is -# required by NXem_ebsd. -# -# The third case study shows how a generic set of Kikuchi pattern -# can be loaded with the em_om parser. The pattern are loaded directly -# from a ZIP file and mapped to an simulation image section for now. -# -# The fourth case study uses the DREAM.3D package which provides an own -# set of EBSD data post-processing procedures. DREAM.3D documents the -# processing steps with a pipeline file which is stored inside DREAM.3D -# output files. In this case study, the parser reads the DREAM.3D file -# and maps data relevant from the perspective of NXem_ebsd plus adds -# relevant IPF color maps as they were computed by DREAM.3D. -# Given that in this case the origin of the data is the DREAM.3D file -# again provenance is kept and more details can be followed upon when -# resolving origin. -# -# These examples offer a first set of suggestions on how to make EBSD -# data injectable into research data management system using schemes -# which themselves are agnostic to the specific RDMS and interoperable. -# Steps of collecting the raw data and post-processing these with custom -# scripts like MTex or commercial tools so far are mainly undocumented. -# The limitation is that a program which consumes results or dump files -# from these tools may not have necessarily all the sufficient information -# available to check if the injected orientation data and color models -# are matching the conventions which a user or automated system has -# injected into an electronic lab notebook from which currently the em_om -# parser collects the conventions and stores them into this NXem_ebsd instance. -# The immediate benefit of the here presented NXem_ebsd concept though -# is that the conventions and reference frame definitions are expected -# in an ELN-agnostic representation to make NXem_ebsd a generally useful -# data scheme for EBSD. -# -# Ideally, the em_om parser would load convention-compliant EBSD data -# and use subsequently a community library to transcode/convert orientation -# conventions and parameterized orientation values. Thereafter, convention- -# compliant default plot(s) could be created that would be truely interoperable. -# -# However, given the variety of post-processing tools available surplus -# the fact that these are not usually executed along standardized -# post-processing workflows which perform exactly the same algorithmic steps, -# this is currently not a practically implementable option. Indeed, first -# developers who wish to implement this would first have to create a library -# for performing such tasks, mapping generally between conventions, -# i.e. map and rotate coordinate systems at the parser level. -# -# The unfortunate situation in EBSD is that due to historical reasons -# and competitive strategies, different players in the field have -# implemented (slightly) different approaches each of which misses -# some part of a complete workflow description which is behind EBSD analyses: -# Sample preparation, measurement, indexing, post-processing, paper... -# -# The here exemplified default plot do not so far apply relevant rotations -# but takes the orientation values as they come from the origin and using -# coloring them as they come. It is thus the scientists responsibility to -# enter and check if the respective dataset is rotation-conventions-wise -# consistent and fit for a particular task. -# -# Ideally, with all conventions defined it can be possible to develop -# a converter which rotates the input data. This application definition -# does not assume this and users should be aware of this limitation. -# -# The key point is that the conventions however are captured and this is -# the most important step to the development of such a generic transcoder -# for creating interoperable EBSD datasets. -# -# Currently the conventions remain in the mind or manual lab book of the -# respective scientists or technicians instead of getting stored and -# communicated with research papers that are written based on -# specific dataset, i.e. database entries. -# -# The default gridded representation of the data should not be -# misinterpreted as the only possible way how EBSD data and OIM -# maps can be created! -# -# Indeed, the most general case is that patterns are collected for -# scan points. The scan generator of an electron microscope is instructed -# to steer the beam in such a way across the specimen surface that the -# beam illuminates certain positions for a certain amount time (usually -# equally-spaced and spending about the same amount of time at each -# position). -# -# Therefore, scan positions can be due to such regular flight plans and -# represent sampling on lines, line stacks, rectangular regions-of- -# interests, but also could instruct spiral, random, or adaptive scans -# instead of tessellations with square or hexagonal pixels. -# -# The majority of EBSD maps is though is reporting results for a regular -# grid (square, hexagon). What matters though in terms of damage induced -# by the electron beam and signal quality is the real electron dose -# history, i.e. for how long the beam exposed which location of the -# specimen. Especially when electron charging occurs (i.e. an excess -# amount of charge accumulates due to e.g. poor conducting away of this -# charge or an improper mounting, too high dose, etc. such details are -# relevant. -# -# Specifically, the default visualization is an inverse pole-figure (IPF) -# map with the usual RGB color coding. Different strategies and -# normalization schemes are in use to define such color coding. -# -# Finally, we should mention that each ipf_map represents data for -# scan points indexed as one phase. The alias/name of this phase should -# be stored in phase_name, the phase_identifier give an ID which must -# not be zero as this value is reserved for non-indexed / null model scan -# points. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXms_ipf_set.yaml b/contributed_definitions/nyaml/NXms_ipf_set.yaml deleted file mode 100644 index a783655a2..000000000 --- a/contributed_definitions/nyaml/NXms_ipf_set.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. -# symbols: -type: group -NXms_ipf_set(NXprocess): - (NXms_ipf): diff --git a/contributed_definitions/nyaml/NXms_mtex_config.yaml b/contributed_definitions/nyaml/NXms_mtex_config.yaml deleted file mode 100644 index b8fee982d..000000000 --- a/contributed_definitions/nyaml/NXms_mtex_config.yaml +++ /dev/null @@ -1,187 +0,0 @@ -category: base -doc: | - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. `_ and - the `MTex source code `_ for details. -type: group -NXms_mtex_config(NXobject): - conventions(NXcollection): - doc: | - Reference frame and orientation conventions. - Consult the `MTex docs `_ for details. - x_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - # enumeration: - # check against v5.12 - z_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - # enumeration: - a_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - # enumeration: - b_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - # enumeration: - euler_angle(NX_CHAR): - doc: | - TODO with MTex developers - enumeration: [unknown, undefined, bunge] - plotting(NXcollection): - doc: | - Settings relevant for generating plots. - font_size(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY - inner_plot_spacing(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY - outer_plot_spacing(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY - marker_size(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY - figure_size(NX_NUMBER): - doc: | - TODO with MTex developers - show_micron_bar(NX_BOOLEAN): - doc: | - True if MTex renders a scale bar with figures. - show_coordinates(NX_BOOLEAN): - doc: | - True if MTex renders a grid with figures. - pf_anno_fun_hdl: - doc: | - Code for the function handle used for annotating pole figure plots. - color_map(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_UNITLESS - dim: (i, 3) - default_color_map(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_UNITLESS - dim: (i, 3) - # phase_color_order: - # doc: | - # TODO with MTex developers - # unit: NX_UNITLESS - # dim: (i,) - color_palette(NX_CHAR): - degree_char(NX_CHAR): - doc: | - TODO with MTex developers - arrow_char(NX_CHAR): - doc: | - TODO with MTex developers - marker(NX_CHAR): - doc: | - TODO with MTex developers - marker_edge_color(NX_CHAR): - doc: | - TODO with MTex developers - marker_face_color(NX_CHAR): - doc: | - TODO with MTex developers - hit_test(NX_BOOLEAN): - doc: | - TODO with MTex developers - miscellaneous(NXcollection): - doc: | - Miscellaneous other settings of MTex. - mosek(NX_BOOLEAN): - doc: | - TODO with MTex developers - generating_help_mode(NX_BOOLEAN): - doc: | - TODO with MTex developers - methods_advise(NX_BOOLEAN): - doc: | - TODO with MTex developers - stop_on_symmetry_mismatch(NX_BOOLEAN): - doc: | - TODO with MTex developers - inside_poly(NX_BOOLEAN): - doc: | - TODO with MTex developers - text_interpreter: - numerics(NXcollection): - doc: | - Miscellaneous settings relevant for numerics. - eps(NX_NUMBER): - doc: | - Return value of the Matlab eps command. - unit: NX_UNITLESS - fft_accuracy(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY # NX_LENGTH or NX_RECIPROCAL_LENGTH? - max_stwo_bandwidth(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY # radiant? - max_sothree_bandwidth(NX_NUMBER): - doc: | - TODO with MTex developers - unit: NX_ANY # radiant? - system(NXcollection): - doc: | - Miscellaneous settings relevant of the system where MTex runs. - memory(NX_NUMBER): - doc: | - TODO with MTex developers - open_gl_bug(NX_BOOLEAN): - doc: | - TODO with MTex developers - save_to_file(NX_BOOLEAN): - doc: | - TODO with MTex developers - path(NXcollection): - doc: | - Collection of paths from where MTex reads information and code. - mtex(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - data(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - cif(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - ebsd(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - pf(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - odf(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - tensor(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - example(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - import_wizard(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - pf_extensions(NX_CHAR): - doc: | - List of file type suffixes for which MTex assumes - texture/pole figure information. - ebsd_extensions(NX_CHAR): - doc: | - List of file type suffixes for which MTex assumes EBSD content. - # version as an instance of (NXprogram) one for MTex one for Matlab diff --git a/contributed_definitions/nyaml/NXms_odf.yaml b/contributed_definitions/nyaml/NXms_odf.yaml deleted file mode 100644 index 92ad96589..000000000 --- a/contributed_definitions/nyaml/NXms_odf.yaml +++ /dev/null @@ -1,99 +0,0 @@ -category: base -doc: | - Base class to store an orientation distribution function (ODF) computation. -symbols: - n_varphi_one: | - Number of pixel per varphi section plot along the varphi_one fastest direction. - n_capital_phi: | - Number of pixel per varphi section plot along the capital_phi slow direction. - n_varphi_two: | - Number of pixel per varphi section plot along the varphi_two slowest direction. - k: | - Number of local maxima evaluated in the component analysis. -type: group -NXms_odf(NXprocess): - configuration(NXobject): - doc: | - Details about the algorithm used for computing the ODF. - crystal_symmetry_point_group(NX_CHAR): - doc: | - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. - specimen_symmetry_point_group(NX_CHAR): - doc: | - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). - kernel_halfwidth(NX_NUMBER): - doc: | - Halfwidth of the kernel. - unit: NX_ANGLE - kernel_name(NX_CHAR): - doc: | - Name of the kernel. - resolution(NX_NUMBER): - doc: | - Resolution of the kernel. - unit: NX_ANGLE - kth_extrema(NXobject): - kth(NX_UINT): - doc: | - Number of local maxima evaluated for the ODF. - unit: NX_UNITLESS - # value of kth should be k - location(NX_NUMBER): - doc: | - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. - unit: NX_ANGLE - dim: (k, 3) - theta(NX_NUMBER): - doc: | - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - unit: NX_ANGLE - volume_fraction(NX_NUMBER): - doc: | - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. - unit: NX_ANY - dim: (k,) - phi_two_plot(NXdata): - doc: | - Visualization of the ODF intensity as orthogonal sections through Euler space. - - This is one example of typical default plots used in the texture - community in Materials Engineering. - - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. - # \@signal: intensity - # \@axes: [varphi_two, capital_phi, varphi_one] - # \@varphi_one_indices: 0 - # \@capital_phi: 1 - # \@varphi_two_indices: 2 - intensity(NX_NUMBER): - doc: | - ODF intensity at probed locations relative to - null model of a completely random texture. - unit: NX_DIMENSIONLESS - dim: (n_varphi_two, n_capital_phi, n_varphi_one) - varphi_one(NX_NUMBER): - doc: | - Pixel center angular position along the :math:`\varphi_1` direction. - unit: NX_ANGLE - dim: (n_varphi_one,) - # \@long_name(NX_CHAR): - varphi_two(NX_NUMBER): - doc: | - Pixel center angular position along the :math:`\varphi_2` direction. - unit: NX_ANGLE - dim: (n_varphi_two,) - # \@long_name(NX_CHAR): - capital_phi(NX_NUMBER): - doc: | - Pixel center angular position along the :math:`\Phi` direction. - unit: NX_ANGLE - dim: (n_capital_phi,) - # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_odf_set.yaml b/contributed_definitions/nyaml/NXms_odf_set.yaml deleted file mode 100644 index 5ea1c4d6c..000000000 --- a/contributed_definitions/nyaml/NXms_odf_set.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to group multiple :ref:`NXms_odf` instances. - - A collection of orientation distribution function approximations. -# symbols: -type: group -NXms_odf_set(NXprocess): - (NXms_odf): diff --git a/contributed_definitions/nyaml/NXms_pf.yaml b/contributed_definitions/nyaml/NXms_pf.yaml deleted file mode 100644 index 09ab12f78..000000000 --- a/contributed_definitions/nyaml/NXms_pf.yaml +++ /dev/null @@ -1,59 +0,0 @@ -category: base -doc: | - Base class to store a pole figure (PF) computation. -symbols: - n_y: | - Number of pixel per pole figure in the slow direction. - n_x: | - Number of pixel per pole figure in the fast direction. -type: group -NXms_pf(NXprocess): - configuration(NXobject): - doc: | - 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 - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). - specimen_symmetry_point_group(NX_CHAR): - doc: | - Point group assumed for processing induced *sample symmetries* - (according to International Table of Crystallography). - halfwidth(NX_NUMBER): - doc: | - Halfwidth of the kernel. - unit: NX_ANGLE - miller_indices(NX_CHAR): - doc: | - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. - resolution(NX_NUMBER): - doc: | - Resolution of the kernel. - unit: NX_ANGLE - pf(NXdata): - doc: | - Pole figure. - # \@signal: intensity - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - intensity(NX_NUMBER): - doc: | - Pole figure intensity. - unit: NX_UNITLESS - dim: (n_y, n_x) - axis_y(NX_NUMBER): - doc: | - Pixel center along y direction in the equatorial plane of - a stereographic projection of the unit sphere. - unit: NX_ANY - dim: (n_y,) - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - doc: | - Pixel center along x direction in the equatorial plane of - a stereographic projection of the unit sphere. - unit: NX_ANY - dim: (n_x,) - # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_pf_set.yaml b/contributed_definitions/nyaml/NXms_pf_set.yaml deleted file mode 100644 index afd785f15..000000000 --- a/contributed_definitions/nyaml/NXms_pf_set.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. -# symbols: -type: group -NXms_pf_set(NXprocess): - (NXms_pf): diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml deleted file mode 100644 index bd6825bac..000000000 --- a/contributed_definitions/nyaml/NXms_recon.yaml +++ /dev/null @@ -1,315 +0,0 @@ -# position would need another depends_on the specific coordinate system used, currently we assume McStas -# roi1/ebsd/microstructure1 -category: base -doc: | - Base class to describe discretized (micro)structural features of a material. - - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - # in so-called linear intercept analysis we observe - # one-dimensional sections of either projections (see below) - # or true one-dimensional cuts across a volume of material - # n_icept: | - # The number of linear intercepts defined. - # n_c_one: | - # The number of crystal projections segmented by crossing (projected or real) interfaces - # n_i_one: | - # The number of crossings - # two-dimensional projections of characterized in reality three-dimensional objects - # using E. E. Underwood notation - # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" - n_c_two: | - The number of crystal projections. - n_i_two: | - The number of interface projections. - n_t_two: | - The number of assumed triple junction projections aka triple points. - # three-dimensional real objects, volumetrically characterized - # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions - n_c: | - The number of crystals. - n_i: | - The number of interfaces - n_t: | - The number of triple lines - n_q: | - The number of quadruple junctions. -type: group -NXms_recon(NXobject): - # as e.g. a result of one grain reconstruction with MTex or othe - # grain reconstruction software in commercial tools - # the idea is we may wish to run as many grain reconstructions as we want... - # add details about the processing - configuration(NXprocess): - doc: | - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. - # maybe a depends_on what was the input however if the group is injected - # in an roi1/ebsd instance isnt this information implicit? - dimensionality(NX_POSINT): - doc: | - Dimensionality of the analysis. - - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - algorithm(NX_CHAR): - doc: | - Which algorithm is used to reconstruct the features. - enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] - disorientation_threshold(NX_NUMBER): - doc: | - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. - unit: NX_ANGLE - # the result of running one grain reconstruction - # ms_feature_set1 - # we could also enumerate instances ms_feature_setID here because configuration - # may specify a range of different parameter resulting in multiple ms_feature_sets - # dimensionality(N) composed from NXms_feature_set base: - # controlled vocabulary of base class instances to be used to inform about the - # discretization of these features instances to discretize the features - # wherever possible the computational geometry specific instances whose - # purpose is only to support/represent the discretization of the features should - # be separated out from the materials engineering interpretation of what these - # features are, i.e. a grain that is measured with a 2d section ends up - # modelled as an projection of that real 3d grain object - # the model is discretized usign a polyline which models the location of the - # interface at the required here coarse-grained continuum picture - points(NXcg_point_set): - lines(NXcg_polyline_set): - surfaces(NXcg_triangle_set): - volumes(NXcg_polyhedron_set): - - # domain-specific, i.e. microstructural features - # ONE DIMENSIONAL FEATURES - - # TWO DIMENSIONAL FEATURES - crystal_projections(NXms_feature_set): - doc: | - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - \@discretization(NX_CHAR): - doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - number_of_crystals(NX_UINT): - doc: | - Number of crystals. - unit: NX_UNITLESS - crystal_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - crystal_identifier(NX_INT): - doc: | - Identifier used for crystals for explicit indexing. - unit: NX_UNITLESS - dim: (n_c_two,) - number_of_phases(NX_UINT): - doc: | - How many phases are distinguished - unit: NX_UNITLESS - phase_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - unit: NX_UNITLESS - phase_identifier(NX_INT): - # \@depends_on(NX_CHAR): - doc: | - Identifier used for phase for explicit indexing. - unit: NX_UNITLESS - dim: (n_c_two,) - # properties of crystal_projections aka grain properties - boundary_contact(NX_BOOLEAN): - doc: | - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - dim: (n_c_two,) - orientation_spread(NX_NUMBER): - doc: | - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. - unit: NX_ANGLE - dim: (n_c_two,) - (NXrotation_set): - area(NX_NUMBER): - doc: | - Calibrated area of surrounded by the polyline about each crystal. - unit: NX_AREA - dim: (n_c_two,) - interface_projections(NXms_feature_set): - # grain boundaries have a network of line-like defects, its explicit description - # often generates unnecessary information duplication and cluttering, - # therefore here a compact and suggestion how to store such data - doc: | - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - \@discretization(NX_CHAR): - doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. - - Set of tuples of polyline segments which build the interface. - # topology - # i) Set of pair of crystals sharing an interface - crystals(NX_INT): - doc: | - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. - unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): - doc: | - The specific crystal_projections(NXms_feature_set) instance - to resolve crystal identifier. - # ii) Set of pair of topologically connected triple points - triple_points(NX_INT): - doc: | - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. - unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): - doc: | - The specific triple_line_projections(NXms_feature_set) instance - whereby to resolve triple_point identifier. - # alternatively which polyline of adjoining interfaces - # properties, descriptors - length(NX_NUMBER): - doc: | - The length of the interface. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - unit: NX_LENGTH - dim: (n_i_two,) - interface_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - interface_identifier(NX_INT): - doc: | - Identifier for each interface using explicit indexing. - unit: NX_UNITLESS - dim: (n_i_two,) - triple_line_projections(NXms_feature_set): - # only for 2D, quad junction is the equivalent for 3D is not a triple_line - # four alternative descriptors with different strength to specify spatial - # or logical information about the triple junction feature set. - # the explicit description often generating unnecessary information duplication - doc: | - Projections of triple lines as typically characterized with optical - or electron microscopy. - - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - \@discretization(NX_CHAR): - doc: | - Reference to points(NXcg_point_set) which supports the - locations of these triple points. - # another view to describe a triple junction is via its topology/connection expressed either via - # i) triplet of interface identifier - number_of_triple_points(NX_UINT): - doc: | - Number of triple points. - unit: NX_UNITLESS - triple_point_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from 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]`. - unit: NX_UNITLESS - triple_point_identifier(NX_INT): - doc: | - Identifier for each triple point using explicit indexing. - unit: NX_UNITLESS - dim: (n_t_two,) - location(NX_INT): - doc: | - Set of triple point identifiers. - unit: NX_UNITLESS - dim: (n_t_two,) - \@depends_on(NX_CHAR): - doc: | - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - interfaces(NX_INT): # aka topology or interfaces - doc: | - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. - unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): - doc: | - The specific interface_projections(NXms_feature_set) - instance whereby to resolve interface identifiers. - # ii) a triplet of line segment identifier whereby the point-like features - # is assumed discretized via three polylines representing interfaces - polylines(NX_INT): - doc: | - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. - unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): - doc: | - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - # the difference in the interpretation of interfaces and polylines - # is that the interface resolves interface (e.g. phase boundary names) - # while polylines resolves segments within the set of named geometric primitive - # instances! - # add all sort of other qualitative or quantitive descriptors (triple junction - # energy, volume etc), i.e properties of that triple point diff --git a/requirements.txt b/requirements.txt index 8ba01346d..4b6ab51d5 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -nyaml==0.0.8 +nyaml # Documentation building sphinx>=5 From 27a9d4b137cd075455938315e8d9f28805f19610 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 24 Sep 2024 12:50:47 +0200 Subject: [PATCH 188/198] remove classes from contributed that have been moved to base_classes --- base_classes/NXcoordinate_system.nxdl.xml | 159 ++++++++++++ .../NXcg_ellipsoid_set.nxdl.xml | 135 ---------- .../NXcg_face_list_data_structure.nxdl.xml | 243 ------------------ .../NXcg_hexahedron_set.nxdl.xml | 239 ----------------- .../NXcg_parallelogram_set.nxdl.xml | 183 ------------- .../NXcg_point_set.nxdl.xml | 98 ------- .../NXcg_polygon_set.nxdl.xml | 225 ---------------- .../NXcg_polyhedron_set.nxdl.xml | 194 -------------- .../NXcg_sphere_set.nxdl.xml | 121 --------- .../NXcg_tetrahedron_set.nxdl.xml | 175 ------------- .../NXcg_triangle_set.nxdl.xml | 132 ---------- 11 files changed, 159 insertions(+), 1745 deletions(-) create mode 100644 base_classes/NXcoordinate_system.nxdl.xml delete mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml new file mode 100644 index 000000000..80de81f40 --- /dev/null +++ b/base_classes/NXcoordinate_system.nxdl.xml @@ -0,0 +1,159 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the third axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + + + + + + + + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e..000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e..000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123..000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a56984..000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839..000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index e90dd652f..000000000 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe..000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf8..000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index b3e27b0f9..000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 3640f8ff3..000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - From 9dd682655323acc2e2bb84f137e131f26d7317e8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 25 Sep 2024 15:43:23 +0200 Subject: [PATCH 189/198] Refactored problematic attribute name depends on --- base_classes/NXcg_half_edge_data_structure.nxdl.xml | 6 ------ base_classes/NXcg_polyline_set.nxdl.xml | 4 ++-- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index 40213352e..fa431c560 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -54,12 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - Dimensionality of the primitives described. diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml index 64a002f86..2965ffc3a 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/base_classes/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,13 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - + Reference to an instance of :ref:`NXcg_point_set` which defines the location of the vertices that are referred to in the NXcg_polyline_set instance. - + The total number of vertices that have different positions. From d2ad17ff6ad00ae7a2096ba2a52ff80750cc4ae8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 8 Jan 2025 16:57:18 +0100 Subject: [PATCH 190/198] Implement suggestion to drop suffix _set to avoid confusion with the semantic meaning that is assigned to the reserved suffix _set (see NeXus Rules for Storing Data Items) --- .../{NXcg_cylinder_set.nxdl.xml => NXcg_cylinder.nxdl.xml} | 0 .../{NXcg_ellipsoid_set.nxdl.xml => NXcg_ellipsoid.nxdl.xml} | 0 .../{NXcg_hexahedron_set.nxdl.xml => NXcg_hexahedron.nxdl.xml} | 0 ...Xcg_parallelogram_set.nxdl.xml => NXcg_parallelogram.nxdl.xml} | 0 base_classes/{NXcg_point_set.nxdl.xml => NXcg_point.nxdl.xml} | 0 base_classes/{NXcg_polygon_set.nxdl.xml => NXcg_polygon.nxdl.xml} | 0 .../{NXcg_polyhedron_set.nxdl.xml => NXcg_polyhedron.nxdl.xml} | 0 .../{NXcg_polyline_set.nxdl.xml => NXcg_polyline.nxdl.xml} | 0 .../{NXcg_primitive_set.nxdl.xml => NXcg_primitive.nxdl.xml} | 0 base_classes/{NXcg_roi_set.nxdl.xml => NXcg_roi.nxdl.xml} | 0 base_classes/{NXcg_sphere_set.nxdl.xml => NXcg_sphere.nxdl.xml} | 0 .../{NXcg_tetrahedron_set.nxdl.xml => NXcg_tetrahedron.nxdl.xml} | 0 .../{NXcg_triangle_set.nxdl.xml => NXcg_triangle.nxdl.xml} | 0 .../{NXcg_unit_normal_set.nxdl.xml => NXcg_unit_normal.nxdl.xml} | 0 14 files changed, 0 insertions(+), 0 deletions(-) rename base_classes/{NXcg_cylinder_set.nxdl.xml => NXcg_cylinder.nxdl.xml} (100%) rename base_classes/{NXcg_ellipsoid_set.nxdl.xml => NXcg_ellipsoid.nxdl.xml} (100%) rename base_classes/{NXcg_hexahedron_set.nxdl.xml => NXcg_hexahedron.nxdl.xml} (100%) rename base_classes/{NXcg_parallelogram_set.nxdl.xml => NXcg_parallelogram.nxdl.xml} (100%) rename base_classes/{NXcg_point_set.nxdl.xml => NXcg_point.nxdl.xml} (100%) rename base_classes/{NXcg_polygon_set.nxdl.xml => NXcg_polygon.nxdl.xml} (100%) rename base_classes/{NXcg_polyhedron_set.nxdl.xml => NXcg_polyhedron.nxdl.xml} (100%) rename base_classes/{NXcg_polyline_set.nxdl.xml => NXcg_polyline.nxdl.xml} (100%) rename base_classes/{NXcg_primitive_set.nxdl.xml => NXcg_primitive.nxdl.xml} (100%) rename base_classes/{NXcg_roi_set.nxdl.xml => NXcg_roi.nxdl.xml} (100%) rename base_classes/{NXcg_sphere_set.nxdl.xml => NXcg_sphere.nxdl.xml} (100%) rename base_classes/{NXcg_tetrahedron_set.nxdl.xml => NXcg_tetrahedron.nxdl.xml} (100%) rename base_classes/{NXcg_triangle_set.nxdl.xml => NXcg_triangle.nxdl.xml} (100%) rename base_classes/{NXcg_unit_normal_set.nxdl.xml => NXcg_unit_normal.nxdl.xml} (100%) diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder.nxdl.xml similarity index 100% rename from base_classes/NXcg_cylinder_set.nxdl.xml rename to base_classes/NXcg_cylinder.nxdl.xml diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid.nxdl.xml similarity index 100% rename from base_classes/NXcg_ellipsoid_set.nxdl.xml rename to base_classes/NXcg_ellipsoid.nxdl.xml diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron.nxdl.xml similarity index 100% rename from base_classes/NXcg_hexahedron_set.nxdl.xml rename to base_classes/NXcg_hexahedron.nxdl.xml diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram.nxdl.xml similarity index 100% rename from base_classes/NXcg_parallelogram_set.nxdl.xml rename to base_classes/NXcg_parallelogram.nxdl.xml diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point.nxdl.xml similarity index 100% rename from base_classes/NXcg_point_set.nxdl.xml rename to base_classes/NXcg_point.nxdl.xml diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon.nxdl.xml similarity index 100% rename from base_classes/NXcg_polygon_set.nxdl.xml rename to base_classes/NXcg_polygon.nxdl.xml diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron.nxdl.xml similarity index 100% rename from base_classes/NXcg_polyhedron_set.nxdl.xml rename to base_classes/NXcg_polyhedron.nxdl.xml diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline.nxdl.xml similarity index 100% rename from base_classes/NXcg_polyline_set.nxdl.xml rename to base_classes/NXcg_polyline.nxdl.xml diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml similarity index 100% rename from base_classes/NXcg_primitive_set.nxdl.xml rename to base_classes/NXcg_primitive.nxdl.xml diff --git a/base_classes/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi.nxdl.xml similarity index 100% rename from base_classes/NXcg_roi_set.nxdl.xml rename to base_classes/NXcg_roi.nxdl.xml diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere.nxdl.xml similarity index 100% rename from base_classes/NXcg_sphere_set.nxdl.xml rename to base_classes/NXcg_sphere.nxdl.xml diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml similarity index 100% rename from base_classes/NXcg_tetrahedron_set.nxdl.xml rename to base_classes/NXcg_tetrahedron.nxdl.xml diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle.nxdl.xml similarity index 100% rename from base_classes/NXcg_triangle_set.nxdl.xml rename to base_classes/NXcg_triangle.nxdl.xml diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml similarity index 100% rename from base_classes/NXcg_unit_normal_set.nxdl.xml rename to base_classes/NXcg_unit_normal.nxdl.xml From 9493eb5335bcf341360233ec692bb06950b516f2 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 10 Jan 2025 17:18:59 +0100 Subject: [PATCH 191/198] Autumn NIAC 2024 edits --- base_classes/NXcg_alpha_complex.nxdl.xml | 75 +++++++------------ base_classes/NXcg_cylinder.nxdl.xml | 30 ++------ base_classes/NXcg_ellipsoid.nxdl.xml | 17 ++++- .../NXcg_face_list_data_structure.nxdl.xml | 23 +++--- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- base_classes/NXcg_primitive.nxdl.xml | 39 ++-------- base_classes/NXcg_sphere.nxdl.xml | 61 --------------- 7 files changed, 68 insertions(+), 183 deletions(-) delete mode 100644 base_classes/NXcg_sphere.nxdl.xml diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index b6a466bc5..24e0466ff 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -23,27 +23,32 @@ --> - + - Computational geometry of alpha shapes or alpha wrappings about primitives. + 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 - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings + * 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. + 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. - Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes - created using the alpha_wrapping algorithm. + Alpha_shape means meshes created using one of the alpha_shape algorithm. + Alpha_wrapping means meshes created using the alpha_wrapping algorithm. @@ -51,72 +56,46 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu - + - Are singular faces removed, i.e. has the alpha complex - been regularized or not. + 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 radius of the alpha-sphere that is used when computing the alpha complex. - The offset distance parameter used when computing alpha_wrappings. - - + - Point cloud for which the alpha shape or wrapping has been computed. + Point cloud serving as input for the computation of the alpha complex. - - + - Triangle soup for which the alpha wrapping has been computed. + Triangle soup serving as input for the computation of the alpha complex. - + - Triangle mesh representing the alpha complex. + Triangle mesh representing the output of the computation, i.e. the alpha complex. - - + - Set of tetrahedra representing the volume inside 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 index e5bb83807..2679da478 100644 --- a/base_classes/NXcg_cylinder.nxdl.xml +++ b/base_classes/NXcg_cylinder.nxdl.xml @@ -24,7 +24,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,33 +41,25 @@ cylinder could be constructed, but NXcylinder is easier to understand--> - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders or (truncated) cones. The radius can either be defined in the radii field or by filling both the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + thus be used to represent (truncated) cones. 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 defined as the one that is farther away to the origin + when inspecting a parallel projection onto the direction vector. - Radius of the cylinder if all have the same radius. @@ -106,7 +98,7 @@ one should really better use NXquadric...--> - Lateral surface area + Lateral surface area of each cylinder. @@ -130,16 +122,10 @@ one should really better use NXquadric...--> - Sum of upper and lower cap areas and lateral surface area - 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 index e22a677c1..2b7a503a1 100644 --- a/base_classes/NXcg_ellipsoid.nxdl.xml +++ b/base_classes/NXcg_ellipsoid.nxdl.xml @@ -23,7 +23,7 @@ --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -61,5 +61,20 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> + + + + 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 half_axes_radii. + + + + + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 081b928d5..d88b24007 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -23,7 +23,7 @@ --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -62,18 +62,17 @@ 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 differ in - their properties. A face-and-edge-list-based description of primitives is + 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 though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. + 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 very detailed specification demands. + useful to embrace both users with small or detailed specification demands. @@ -159,10 +158,10 @@ 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 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. + 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. diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index fa431c560..deca0280c 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -194,8 +194,4 @@ of microstructural objects like crystals/grains. - diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml index 034216a3e..14edab31d 100644 --- a/base_classes/NXcg_primitive.nxdl.xml +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -21,34 +21,14 @@ # # For further information, see http://www.nexusformat.org --> - - + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality of the space. + The dimensionality of the embedding space. @@ -63,9 +43,6 @@ on your data...--> 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 @@ -122,7 +99,6 @@ to enable an instantiation of the actual geometric primitives--> - True if the center is a center of mass. @@ -201,12 +177,7 @@ to enable an instantiation of the actual geometric primitives--> - - - - + + + diff --git a/base_classes/NXcg_sphere.nxdl.xml b/base_classes/NXcg_sphere.nxdl.xml deleted file mode 100644 index 8b1283474..000000000 --- a/base_classes/NXcg_sphere.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - From d892c17f5d3e826c30445b8e106052470d0f98d8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 10 Jan 2025 17:55:36 +0100 Subject: [PATCH 192/198] Consolidated content of too small base classes by merging these definitions into meatier base classes for primitives, further Autumn NIAC 2024 refactoring --- base_classes/NXcg_geodesic_mesh.nxdl.xml | 55 -------------------- base_classes/NXcg_grid.nxdl.xml | 32 ++++++++++-- base_classes/NXcg_hexahedron.nxdl.xml | 16 +++--- base_classes/NXcg_marching_cubes.nxdl.xml | 61 ----------------------- base_classes/NXcg_primitive.nxdl.xml | 46 +++++++++++++++++ base_classes/NXcg_unit_normal.nxdl.xml | 2 +- 6 files changed, 81 insertions(+), 131 deletions(-) delete mode 100644 base_classes/NXcg_geodesic_mesh.nxdl.xml delete mode 100644 base_classes/NXcg_marching_cubes.nxdl.xml diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml deleted file mode 100644 index 6314db342..000000000 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of a geodesic mesh. - - 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. - - - - diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 4d5aced5f..7468c6168 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,9 +46,10 @@ 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. Examples of numerical methods where grids are used - are spectral-solver based crystal plasticity or other stencil methods like - phase-field or cellular automata. + 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. @@ -112,7 +113,7 @@ should constraints on the grid be place here or not--> - + A tight bounding box about the grid. @@ -152,4 +153,25 @@ 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, tech repor, or free-text description + is possible. + + diff --git a/base_classes/NXcg_hexahedron.nxdl.xml b/base_classes/NXcg_hexahedron.nxdl.xml index 8ea85fb98..521fe89f0 100644 --- a/base_classes/NXcg_hexahedron.nxdl.xml +++ b/base_classes/NXcg_hexahedron.nxdl.xml @@ -27,7 +27,7 @@ a polyhedron is a specific polytope in 3d, do we need higher-dimensional polytopes? that could be useful for simplicies though as they are used in numerics etc. maybe reach out here to our friends from MarDI, for now let's assume we do not need polytopes for d > 3--> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -65,7 +65,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> 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_set` base class hexahedra + 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. @@ -169,23 +169,21 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - - - - + + + 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_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml deleted file mode 100644 index 4cc765fd8..000000000 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of the marching cubes algorithm. - - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. - - - - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. - - - - - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: - - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. - - - - - diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml index 14edab31d..1b0ac9ebd 100644 --- a/base_classes/NXcg_primitive.nxdl.xml +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -177,6 +177,52 @@ + + + Do the primitives define a mesh. + + + + + + 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_unit_normal.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml index 21470b34f..3a53990ed 100644 --- a/base_classes/NXcg_unit_normal.nxdl.xml +++ b/base_classes/NXcg_unit_normal.nxdl.xml @@ -25,7 +25,7 @@ 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--> - + From 09f1d6ebdfaa74fb34b462f254341ed26b780777 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 10 Jan 2025 18:21:20 +0100 Subject: [PATCH 193/198] Refactored remaining docstrings to remove _set, and refactoring of remaining cg base classes --- .../NXcg_face_list_data_structure.nxdl.xml | 6 +++--- base_classes/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +++--- base_classes/NXcg_parallelogram.nxdl.xml | 13 ++++-------- base_classes/NXcg_point.nxdl.xml | 6 +++--- base_classes/NXcg_polygon.nxdl.xml | 21 +++++++------------ base_classes/NXcg_polyhedron.nxdl.xml | 8 +++---- base_classes/NXcg_polyline.nxdl.xml | 11 ++++------ base_classes/NXcg_roi.nxdl.xml | 17 +++++++-------- base_classes/NXcg_tetrahedron.nxdl.xml | 16 +++----------- base_classes/NXcg_triangle.nxdl.xml | 9 ++------ base_classes/NXcg_unit_normal.nxdl.xml | 2 +- 12 files changed, 44 insertions(+), 73 deletions(-) diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index d88b24007..9f7181f52 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -108,7 +108,7 @@ duplicate of an NXoff_geometry ?--> of the vertices differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + Inspect the definition of NXcg_primitive for further details. @@ -117,7 +117,7 @@ duplicate of an NXoff_geometry ?--> of the edges differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + Inspect the definition of NXcg_primitive for further details. @@ -126,7 +126,7 @@ duplicate of an NXoff_geometry ?--> of the faces differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. + Inspect the definition of NXcg_primitive for further details. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 7468c6168..69b7be5e6 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -55,7 +55,7 @@ Location of the origin of the grid. - Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` + 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. diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index deca0280c..5cab4bb65 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -93,7 +93,7 @@ of the vertices differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -102,7 +102,7 @@ of the edges differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + Inspect the definition of :ref:`NXcg_primitive` for further details. @@ -111,7 +111,7 @@ of the faces differs from zero. Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + Inspect the definition of :ref:`NXcg_primitive` for further details. diff --git a/base_classes/NXcg_parallelogram.nxdl.xml b/base_classes/NXcg_parallelogram.nxdl.xml index bfb868c47..14660d463 100644 --- a/base_classes/NXcg_parallelogram.nxdl.xml +++ b/base_classes/NXcg_parallelogram.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -55,7 +55,7 @@ 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_set` for the generalization in 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 @@ -89,18 +89,13 @@ - - Combined storage of all primitives of all parallelograms. + 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 index c2190590d..acc8b6cbc 100644 --- a/base_classes/NXcg_point.nxdl.xml +++ b/base_classes/NXcg_point.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -42,12 +42,12 @@ 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_set` instance which specifies the + 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 time stamp + simulated physical time). Thereby, the storage of redundant timestamp information per point is considered as obsolete. diff --git a/base_classes/NXcg_polygon.nxdl.xml b/base_classes/NXcg_polygon.nxdl.xml index 95c157ce1..151f10d0d 100644 --- a/base_classes/NXcg_polygon.nxdl.xml +++ b/base_classes/NXcg_polygon.nxdl.xml @@ -21,10 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,9 +43,7 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -65,14 +60,14 @@ somewhat redundant as there is NXoff_geometry but easier to understand 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_set` base class if they wish to describe closed + 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_set to describe such even more - complex primitives instead of abusing this base class for such purposes. + 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. @@ -85,12 +80,12 @@ somewhat redundant as there is NXoff_geometry but easier to understand Combined storage of all primitives of all polygons. - + Individual storage of the mesh of each polygon. - + Individual storage of each polygon as a graph. diff --git a/base_classes/NXcg_polyhedron.nxdl.xml b/base_classes/NXcg_polyhedron.nxdl.xml index b087b0c79..a6238e1d0 100644 --- a/base_classes/NXcg_polyhedron.nxdl.xml +++ b/base_classes/NXcg_polyhedron.nxdl.xml @@ -31,7 +31,7 @@ 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.--> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -61,7 +61,7 @@ for clean graph-based descriptions of polyhedra.--> 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_set`. + by creating customized instances of an :ref:`NXcg_polygon`. @@ -101,12 +101,12 @@ for clean graph-based descriptions of polyhedra.--> 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 index 2965ffc3a..d24cda949 100644 --- a/base_classes/NXcg_polyline.nxdl.xml +++ b/base_classes/NXcg_polyline.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,9 +59,9 @@ multiple vertices possible with the same point coordinates but different names.- - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. + Reference to an instance of :ref:`NXcg_point` which defines the + location of the vertices that are referred to in the + NXcg_polyline instance. @@ -106,9 +106,6 @@ they share the same position in space but have different identifiers.--> - If true indicates that the vertices are all placed at different diff --git a/base_classes/NXcg_roi.nxdl.xml b/base_classes/NXcg_roi.nxdl.xml index 69bc0042e..360a2274e 100644 --- a/base_classes/NXcg_roi.nxdl.xml +++ b/base_classes/NXcg_roi.nxdl.xml @@ -23,12 +23,12 @@ --> - + 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_set` base class surplus + :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 @@ -46,12 +46,11 @@ eventually redundant NXsolid_geometry?--> region in space (and time) where an observation is made or for which a computer simulation is performed with given boundary conditions. - - - - - - + + + + + +see comment to NXcg_triangle roi--> diff --git a/base_classes/NXcg_tetrahedron.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml index 509347c51..074890252 100644 --- a/base_classes/NXcg_tetrahedron.nxdl.xml +++ b/base_classes/NXcg_tetrahedron.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -58,27 +58,17 @@ - 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 index 7d994eb3e..233233e15 100644 --- a/base_classes/NXcg_triangle.nxdl.xml +++ b/base_classes/NXcg_triangle.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -58,18 +58,13 @@ 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. diff --git a/base_classes/NXcg_unit_normal.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml index 3a53990ed..0cb4c2da1 100644 --- a/base_classes/NXcg_unit_normal.nxdl.xml +++ b/base_classes/NXcg_unit_normal.nxdl.xml @@ -46,7 +46,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> 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_set` + 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. From 8c6786a86fa90fad789aa273d9e01c7941ee7922 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 10 Jan 2025 18:23:40 +0100 Subject: [PATCH 194/198] Indentation --- base_classes/NXcg_tetrahedron.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/base_classes/NXcg_tetrahedron.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml index 074890252..40393fb62 100644 --- a/base_classes/NXcg_tetrahedron.nxdl.xml +++ b/base_classes/NXcg_tetrahedron.nxdl.xml @@ -65,12 +65,12 @@ - Individual storage of each tetrahedron. + Individual storage of each tetrahedron. - Individual storage of each tetrahedron as a graph. + Individual storage of each tetrahedron as a graph. From 3245ef33449254458c061dc076bac6c7a94dc99c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 10 Jan 2025 18:24:23 +0100 Subject: [PATCH 195/198] Typo in xsd parameter --- base_classes/NXcg_tetrahedron.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/base_classes/NXcg_tetrahedron.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml index 40393fb62..6a876ca6c 100644 --- a/base_classes/NXcg_tetrahedron.nxdl.xml +++ b/base_classes/NXcg_tetrahedron.nxdl.xml @@ -68,7 +68,7 @@ Individual storage of each tetrahedron. - + Individual storage of each tetrahedron as a graph. From 9a13cfa125f55fc39d1bfd23f3eb3231d3499773 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 17 Jan 2025 15:54:32 +0100 Subject: [PATCH 196/198] Addressed comments from @PeterC-DLS --- base_classes/NXcg_alpha_complex.nxdl.xml | 6 +-- base_classes/NXcg_cylinder.nxdl.xml | 16 ++++--- base_classes/NXcg_ellipsoid.nxdl.xml | 11 ++--- .../NXcg_face_list_data_structure.nxdl.xml | 5 --- base_classes/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 10 ++--- base_classes/NXcg_polyline.nxdl.xml | 18 ++++---- base_classes/NXcg_primitive.nxdl.xml | 43 +++++++++++++------ base_classes/NXcg_unit_normal.nxdl.xml | 2 +- 9 files changed, 61 insertions(+), 54 deletions(-) diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml index 24e0466ff..0d45d6696 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -66,10 +66,10 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu Was the alpha complex regularized, i.e. have singular faces been removed, or not. - + - The alpha parameter, i.e. the radius of the alpha-sphere that - is used when computing the alpha complex. + The alpha parameter, i.e. the squared radius of the alpha-sphere + that is used when computing the alpha complex. diff --git a/base_classes/NXcg_cylinder.nxdl.xml b/base_classes/NXcg_cylinder.nxdl.xml index 2679da478..e1099888e 100644 --- a/base_classes/NXcg_cylinder.nxdl.xml +++ b/base_classes/NXcg_cylinder.nxdl.xml @@ -21,9 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -43,17 +40,22 @@ cylinder could be constructed, but NXcylinder is easier to understand--> Computational geometry description of a set of cylinders or (truncated) cones. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can + 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 defined as the one that is farther away to the origin - when inspecting a parallel projection onto the direction vector. + 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. diff --git a/base_classes/NXcg_ellipsoid.nxdl.xml b/base_classes/NXcg_ellipsoid.nxdl.xml index 2b7a503a1..86660bdac 100644 --- a/base_classes/NXcg_ellipsoid.nxdl.xml +++ b/base_classes/NXcg_ellipsoid.nxdl.xml @@ -42,9 +42,10 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Computational geometry description of a set of ellipsoids. - + - Radius of the half axes. + 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. @@ -52,9 +53,9 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> - + - Half-axes radii of each ellipsoid. + Length of the semi-axes if ellipsoids have individually different length. @@ -70,7 +71,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that all ellipsoids are spheres whose radii differ. - For a mixture of spheres use half_axes_radii. + 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 index 9f7181f52..83ba78029 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -53,11 +53,6 @@ duplicate of an NXoff_geometry ?--> The total number of vertices of all faces. Faces are polygons. - - - The total number of Weinberg vector values of all faces. - - Computational geometry of primitives via a face-and-edge-list data structure. diff --git a/base_classes/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml index 69b7be5e6..22f5c093d 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -170,8 +170,8 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele * `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, tech repor, or free-text description - is possible. + If not possible, an identifier for a paper, tech 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 index 5cab4bb65..ef44041a7 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -52,7 +52,8 @@ Computational geeometry description of a half-edge data structure. Such a data structure can be used to efficiently circulate around faces - and iterate over vertices of a planar graph. + and iterate over vertices of a planar graph. The data structure is also + known as a doubly connected edge list. @@ -79,14 +80,9 @@ irrespectively whether edges are shared across faces or not. - + - - - Number of faces of the primitives. - - Integer offset whereby the identifier of the first member diff --git a/base_classes/NXcg_polyline.nxdl.xml b/base_classes/NXcg_polyline.nxdl.xml index d24cda949..8ca7ed64c 100644 --- a/base_classes/NXcg_polyline.nxdl.xml +++ b/base_classes/NXcg_polyline.nxdl.xml @@ -54,13 +54,13 @@ multiple vertices possible with the same point coordinates but different names.- Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when + 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 the + location of the vertices that are referred to in this NXcg_polyline instance. @@ -78,8 +78,6 @@ multiple vertices possible with the same point coordinates but different names.- The total number of vertices of each polyline, irrespectively whether vertices are shared by vertices or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. @@ -118,9 +116,9 @@ 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 in a junction, say the second vertex is shared - and marking the junction between the two polylines, it is possible that - there are only five unique positions. This suggests to store five + 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 @@ -131,9 +129,9 @@ they share the same position in space but have different identifiers.--> 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, the vertices of the - n-th polyline can be accessed on the following array index interval: - :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. + 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 index 1b0ac9ebd..543f82744 100644 --- a/base_classes/NXcg_primitive.nxdl.xml +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -51,9 +51,9 @@ - The dimensionality of the primitive set. + The dimensionality of the primitive set with value up to d. - + @@ -61,7 +61,7 @@ - The cardinality of the primitive set. + The cardinality of the primitive set. Value should be equal to c. @@ -92,7 +92,7 @@ - The center of mass position of each primitive. + The center of each primitive @@ -109,7 +109,7 @@ - A qualitative description of the shape of each primitive. + Shape of each primitive @@ -118,9 +118,9 @@ - Qualifier for the length of characteristic features of the primitive. + Length of each primitive - Often the term length is associated with the assumption that one + Often the term is associated with the assumption that one edge is parallel to an axis of the coordinate system. @@ -129,8 +129,21 @@ - Qualifier often used to describe the length of one characteristic edge - within 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. @@ -144,11 +157,13 @@ - + 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 a an alias for the two-dimensional case. @@ -182,16 +197,16 @@ Do the primitives define a mesh. - + Do the primitives define a geodesic mesh or not. diff --git a/base_classes/NXcg_unit_normal.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml index 0cb4c2da1..5c6b493f7 100644 --- a/base_classes/NXcg_unit_normal.nxdl.xml +++ b/base_classes/NXcg_unit_normal.nxdl.xml @@ -60,7 +60,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - Qualifier which details the orientation of each normal vector + 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. From 9ba70cf2daa6382f927ee10e5f380b7e6f8b46b3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 17 Jan 2025 15:56:25 +0100 Subject: [PATCH 197/198] Temporarily deactivated open flag for enumeration as #1521 not yet merged --- base_classes/NXcg_primitive.nxdl.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml index 543f82744..a908de8eb 100644 --- a/base_classes/NXcg_primitive.nxdl.xml +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -53,7 +53,8 @@ The dimensionality of the primitive set with value up to d. - + + From 9f6becc8b0a98236b07a564eae0db4030c7a508e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 17 Jan 2025 16:50:43 +0100 Subject: [PATCH 198/198] Refactored remaining identifier to follow the identifier_* design to allow that these can also profit from identifierNAME from NXobject --- base_classes/NXcg_face_list_data_structure.nxdl.xml | 12 ++++++------ base_classes/NXcg_half_edge_data_structure.nxdl.xml | 8 ++++---- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml index 83ba78029..51b1a501a 100644 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -97,7 +97,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 +106,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 +115,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 +124,7 @@ duplicate of an NXoff_geometry ?--> Inspect the definition of NXcg_primitive for further details. - + Integer identifier to distinguish all vertices explicitly. @@ -132,7 +132,7 @@ duplicate of an NXoff_geometry ?--> - + Integer used to distinguish all edges explicitly. @@ -140,7 +140,7 @@ duplicate of an NXoff_geometry ?--> - + Integer used to distinguish all faces explicitly. diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml index ef44041a7..9f1e7f9c2 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -83,7 +83,7 @@ - + Integer offset whereby the identifier of the first member of the vertices differs from zero. @@ -92,7 +92,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 +101,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 +110,7 @@ Inspect the definition of :ref:`NXcg_primitive` for further details. - + The position of the vertices.